-
Notifications
You must be signed in to change notification settings - Fork 63
Description
I always noticed on semi-large repostiories, magithub would slow down magit-status a lot. After seeing this in offline mode, I realized this is actually mostly performance problems, and not waiting for api calls.
I took a stacktrace of magit-status called repeatedly for qutebrowser/qutebrowser (with 400 issues, and about 20 prs)`
- command-execute 9119 93%
- call-interactively 9119 93%
- apply 9119 93%
- call-interactively@ido-cr+-record-current-command 9119 93%
- apply 9119 93%
- #<subr call-interactively> 9119 93%
- funcall-interactively 9103 93%
- magit-status 8574 88%
- magit-status-internal 8574 88%
- magit-mode-setup 8574 88%
- magit-mode-setup-internal 8574 88%
- magit-refresh-buffer 8423 86%
- apply 8376 85%
- magit-status-refresh-buffer 8112 83%
- magit-run-section-hook 8032 82%
- run-hooks 8032 82%
- magithub-issue--insert-issue-section 7346 75%
- magithub-issue-insert-sections 7332 75%
- mapcar 7332 75%
- #<compiled 0x30199e9> 7332 75%
- magithub-issue-insert-section 7300 74%
- run-hook-with-args 6616 67%
- magithub-issue-detail-insert-body-preview 1432 14%
+ s-word-wrap 1220 12%
+ #<compiled 0x1fbe465> 56 0%
generate-new-buffer 36 0%
+ s-trim 32 0%
replace-regexp-in-string 8 0%
+ magithub-issue-detail-insert-labels 331 3%
+ magithub-issue-detail-insert-assignees 190 1%
+ magithub-issue-detail-insert-author 145 1%
magit-get-section 32 0%
+ magit-insert-heading 20 0%
+ run-hook-with-args-until-success 8 0%
+ magithub-issues 6 0%
+ magithub-issue--insert-pr-section 260 2%
+ magit-insert-status-headers 131 1%
+ magit-insert-merge-log 11 0%
+ magit-insert-unpulled-from-upstream 4 0%
+ magit-insert-unpulled-from-pushremote 4 0%
+ magit-insert-staged-changes 4 0%
+ magit-section-show 68 0%
+ magit-display-buffer 53 0%
+ magit-status-mode 41 0%
+ run-hooks 20 0%
+ smex 529 5%
+ byte-code 16 0%
+ ... 558 5%
+ redisplay_internal (C function) 44 0%
+ timer-event-handler 8 0%
+ sp--save-pre-command-state 5 0%
+ evil-repeat-pre-hook 4 0%
+ erc-server-filter-function 4 0%
It turns out 75% of time is spent generating the details for issues (which I feel can be optimized down).
Right away I saw a possible improvement where we can trim the string description before wrapping it (rather than after), as 12% of time is spent wrapping long descriptions (that are never used later)
run-hook-with-args seems to be taking a huge chunk of time itself, I'm not entirely sure why. I'm going to play with making that hook a function instead, and seeing if that improves performance (or gives me a better profile to look at).
I'm more than happy to work on this, because I like this kind of thing a lot :). It might be a while before I can work on it though.