Magit extremely slow in Windows. How do I optimize?

Question

I am forced to use Windows 10 for a project. Yes, I would rather use GNU/Linux. To keep my sanity, I've tried to regard Windows as a bootloader for Emacs :)

Unfortunately, Magit (one of my favorite parts of Emacs, which also makes up for the lack of a good command line on Windows) is unbearably slow. I have an SSD, 16 GB of RAM and a quad-core i7 but it takes eight seconds to execute magit-status on a small repository. Then, when I want to stage another change, it takes about 5 seconds per file.

Here's what I've tried:

• $ git config --global core.preloadindex true
• $ git config --global core.fscache true
• $ git config --global gc.auto 256
• Adding the entire project to the Windows Defender (my only AV) exclusion list
• Setting the magit-git-executable to the regular msysgit one I downloaded (https://git-for-windows.github.io/). I checked and git status here takes < 1 second. I know that magit-status does way more, but this is too much.

Can anyone suggest ways to make this faster? I can't imagine anyone using Magit on Windows like this.

It was suggested that this question is a duplicate, but they asked:

I'm struggling to understand why Emacs have noticeably shorter startup time on Ubuntu than Windows. Anyone knows the answer?

I know at least some reasons why Emacs, Git, and Magit are slower on Windows. I am asking how do I optimize Magit to do fewer things, or cache results, or something, even if it's at the expense of functionality.

Answer 1

I have actually done rather a lot of research on this and fundamentally the problem is that git for windows sucks

This is the upstream bug: https://github.com/git-for-windows/git/issues/596 and it requires somebody to rewrite shell scripts in C so that there is no more command forking. For me, its the interactive rebase that is the real killer (I can kick off an interactive rebase, go make tea, come back, read some news, drink the tea, and then maybe it's finished. It's much worse than a lot of people think it is), but general status-like calls are also enough to interrupt the work stride.

An alternative might be to update jGit to support the commands that magit uses, and then run it in nailgun to reduce the JVM startup time, I started a thread to discuss this: http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg03064.html

You might want to read https://stackoverflow.com/questions/4485059 for some potential speedups, but honestly you'll barely notice them.

Something you can do in magit is to follow the author's advice in setting up a minimal magit-status just for staging

;; WORKAROUND https://github.com/magit/magit/issues/2395
(define-derived-mode magit-staging-mode magit-status-mode "Magit staging"
  "Mode for showing staged and unstaged changes."
  :group 'magit-status)
(defun magit-staging-refresh-buffer ()
  (magit-insert-section (status)
    (magit-insert-untracked-files)
    (magit-insert-unstaged-changes)
    (magit-insert-staged-changes)))
(defun magit-staging ()
  (interactive)
  (magit-mode-setup #'magit-staging-mode))

so, do you know any experienced C or Java developers who'd be able to help with either of the solutions to fix git or jGit?

Answer 2

Having recently looked at the a list of call-process calls from magit-status for another reason, it occured to me that some of them can be cached. With the following advice magit-status on Magit's repo goes from 1.9 to 1.3 seconds (my previous measurement of 0.8s mentioned in the comments was for a different (faster) computer). If you are already using magit-staging from the other answer it's probably not going to help much: I saw a reduction from 0.16 to 0.12 seconds (but that's barely larger than measurement noise).

WARNING: This doesn't take care of updating the cache, so things may go wrong (especially if you are fiddling with your git configuration).

(defvar-local magit-git--git-dir-cache nil)
(defvar-local magit-git--toplevel-cache nil)
(defvar-local magit-git--cdup-cache nil)

(defun memoize-rev-parse (fun &rest args)
  (pcase (car args)
    ("--git-dir"
     (unless magit-git--git-dir-cache
       (setq magit-git--git-dir-cache (apply fun args)))
     magit-git--git-dir-cache)
    ("--show-toplevel"
     (unless magit-git--toplevel-cache
       (setq magit-git--toplevel-cache (apply fun args)))
     magit-git--toplevel-cache)
    ("--show-cdup"
     (let ((cdup (assoc default-directory magit-git--cdup-cache)))
       (unless cdup
         (setq cdup (cons default-directory (apply fun args)))
         (push cdup magit-git--cdup-cache))
       (cdr cdup)))
    (_ (apply fun args))))

(advice-add 'magit-rev-parse-safe :around #'memoize-rev-parse)

(defvar-local magit-git--config-cache (make-hash-table :test 'equal))

(defun memoize-git-config (fun &rest keys)
  (let ((val (gethash keys magit-git--config-cache :nil)))
    (when (eq val :nil)
      (setq val (puthash keys (apply fun keys) magit-git--config-cache)))
    val))

(advice-add 'magit-get :around #'memoize-git-config)
(advice-add 'magit-get-boolean :around #'memoize-git-config)

Answer 3

Use Emacs on WSL.

I did an extensive use of magit when I worked on a Linux box.
But was kind of forced to use Windows 10.
I tried to use Magit though I couldn't stand how slow it was.
So I just switched to SublimeMerge for git use.
After one year using it, I haven't looked back.

But since I have tried native Emacs on Windows and Emacs on WSL...
Just made a test to check magit-status on same repo.
I manually started a stopwatch with a hotkey in Windows.
So there is a bit of time gap between when magit-status ends and when the watch stops.

In my case Emacs-on-WSL beats Emacs-on-Windows by ~2 secs vs ~6 secs.
Both tests made starting emacs with emacs -Q.