4

For the last few months, committing even tiny changes using magit (c c) is really slow to bring up the commit message buffer. I've profiled the code that is executing during that time but I'm not really sure what to look for. Here is a profile with the most expensive nodes expanded:

- server-process-filter                                          6065  53%
 - funcall                                                       6065  53%
  - #<compiled 0x15b1c9f>                                        6065  53%
   - funcall                                                     6065  53%
    - #<compiled 0x15b1cab>                                      6065  53%
     - server-execute-continuation                               6065  53%
      - funcall                                                  6065  53%
       - #<compiled 0x17a837f>                                   6065  53%
        - #<compiled 0x17a836b>                                  6065  53%
         - server-execute                                        6065  53%
          - funcall                                              6065  53%
           - #<compiled 0x17a83cf>                               6065  53%
            - funcall                                            6065  53%
             - #<compiled 0x17a8431>                             6065  53%
              - server-visit-files                               6050  53%
               - apply                                           6050  53%
                - #<compiled 0x4639b1>                           6050  53%
                 - find-file-noselect                            6050  53%
                  - find-file-noselect-1                         6047  53%
                   - after-find-file                             6047  53%
                    - run-hooks                                  5147  45%
                     - git-commit-setup-check-buffer               5147  45%
                      - git-commit-setup                         5147  45%
                       - git-commit-setup-font-lock               3184  28%
                        - regexp-opt                             3153  27%
                         + regexp-opt-group                      2385  21%
                           delete-dups                            756   6%
                        - magit-list-remote-branch-names                 23   0%
                         + magit-list-refnames                     23   0%
                       - normal-mode                             1963  17%
                        - funcall                                1015   8%
                         + #<compiled 0x22c05f>                  1015   8%
                        - fundamental-mode                        948   8%
                         + run-mode-hooks                         948   8%
                    + normal-mode                                 900   7%
              + run-hooks                                          11   0%
- ...                                                            4264  37%
   Automatic GC                                                  4239  37%
 + magit-insert-unpushed-to-upstream-or-recent                     17   0%
 + company-post-command                                             4   0%
 + vc-backend                                                       4   0%
+ command-execute                                                 868   7%
+ redisplay_internal (C function)                                  64   0%
+ timer-event-handler                                              52   0%
  company-quickhelp-mode-check-buffers                              4   0%
+ mouse-fixup-help-message                                          1   0%

Any ideas?

UPDATE

I'm able to reproduce with the following minimal init.el file:

(require 'package)
(setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/")
                         ("melpa" . "http://melpa.org/packages/")))
(package-initialize)

(require 'use-package)

(use-package magit
  :ensure t
  :bind ("C-x g" . magit-status))
| improve this question | |
  • In these cases, I try commenting all my config, and slowly uncommenting by parts until I narrow down to the guilty line. Also, if you keep your config under git, you can revert back to when the problem didn't happen and, with git diff, see which changes could be the cause. – Jesse Mar 19 '18 at 17:03
  • @Jesse good suggestion. I've updated the question with a complete init.el that I can reproduce the problem with – thehouse Mar 19 '18 at 17:46
  • Then it's probably something related to your system. Are you using Windows? Magit is known to have performance under Windows. Another thing that crosses my mind is that this could be related to a specific repo. If you try to commit on another, smaller, git repository, do you still experience performance issues? – Jesse Mar 19 '18 at 18:34
  • regexp-opt seems to be taking a larger proportion than I would have expected. Do you have a lot of branches? Looking at the source I see (regexp-opt (magit-list-local-branch-names)) and (regexp-opt (magit-list-remote-branch-names)). – npostavs Mar 20 '18 at 2:25
  • @npostavs Yes the repo I'm working on has 14101 remote branches. I'm not able to control that. I'm not sure why Magit needs the remote branches to show the commit window. – thehouse Mar 20 '18 at 11:19
3

Do you really need all of those branches locally? If not, then it might be a good idea to only track the interesting ones. Such an unusually large number of branches will also affect other things.

To that, replace in .git/config:

[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*

with

[remote "origin"]
    fetch = +refs/heads/master:refs/remotes/origin/master
    fetch = +refs/heads/next:refs/remotes/origin/next
    ...

And then get rid of the other branches using one of the techniques described in the answers to https://stackoverflow.com/questions/15650184/how-to-remove-all-remote-tracking-branches-that-still-exist-on-remote-but-no-lon.

But at least here that should not be necessary anymore thanks to this commit.

| improve this answer | |
  • Thanks for your suggestion. The patch didn't work: Wrong type argument: sequencep, identity. Changing the remote fetch didn't work either. I think I have to clean up the remote branches somehow. I'll look into that – thehouse Mar 21 '18 at 14:17
  • Ups I flipped argument order. Try again with the updated patch. – tarsius Mar 21 '18 at 14:20
  • I added a note about pruning to my answer. – tarsius Mar 21 '18 at 14:23
  • Okay then, I have pushed it. – tarsius Mar 21 '18 at 14:31
  • M p origin RET doesn't delete the remote tracking branches that are no longer in the refspec as they still exist on the remote. For ways to remove the unwanted branches see stackoverflow.com/questions/15650184/… – Tom Jan 30 '19 at 8:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.