Hacker News Reader

Comment by grumpyprole | Hacker News Reader

Magit is unfortunately so slow on Windows that it's unusable. This is a real shame, because the UI is fantastic. I think a better architecture would use libgit2 calls rather than launching multiple git processes for every single magit operation.

View on HN

Magit is not particularly fast on *nix either. Most of the UI operates on buffers which are prepared infrequently, so the latency doesn't have significant impact. This is a very good UI design for magit itself, since staying within emacs provides bigger benefits in most cases.

However, my own cited example about browsing history and blames is one case where I cannot just stomach the subpar efficiency. Tig also runs git as a subprocess, but every view is truly incremental and you can scroll through any buffer in any view and there's absolutely zero delay. Night and day even when comparing emacs with JIT.

Like for magit, tig has one keystroke shortcuts that make sense (which IMHO is pretty common on good TUI programs) and can perform many git operations directly from the spot you're looking at.

I also consider the visual space usage in tig to be much more efficient as well. Especially the blame view, which I find still wasteful in all modes compared to tig's. I frequently use a customized vc-annotate instead.

Magit hooks also considerably slow down operations on remote files, which can be quite annoying if you don't actively need to use git while editing.

Don't get me wrong - I like magit. But like org-mode, I don't get the glorification it gets.

Is the launching of processes on Windows so much slower than on Unix-type OSes that it would cause it to be "so slow" for that reason?

Maybe the reason is another? Personally, I once had Magit act real slow at times because git-annex had added some git hook for something that I didn't need. Just removing that hook improved performance massively. Perhaps something similar is happening.

Also, I'm not sure Emacs Lisp can interface directly with C libraries, so using libgit2 might not be an option.

Unfortunately, it's pretty slow on macOS, as well. I love Magit, but there are times when I feel like it's hindering me more than helping due to the performance.

I use it on a low spec MacBook Air, and it works just fine for me... never noticed any kind of slowness.

I only work on Emacs in small projects though... so maybe that's why it's fast for me?!

Yes it will depend on repository size.

That, and I often have multiple projects open at once. There's a note in the Magit manual about this and how it affects performance, but unfortunately, the workaround means that buffers don't get refreshed and you might see stale information unless you perform a manual refresh.

I noticed better performance using native-comp in magit (and the rest of emacs for what it’s worth) on macOS. Might be worth a shot!

> Also, I'm not sure Emacs Lisp can interface directly with C libraries, so using libgit2 might not be an option.

I believe these days (i.e. since emacs 25) it can via dynamic modules. There are ffi libraries built on top of it.

I'm pretty sure it's the main reason. Look how many times Magit shells out to git to render the status buffer, too many to count: https://github.com/magit/magit/issues/1327

In a perfect world, Emacs would link to libgit2 and Magit would be adapted and folded into the core distribution.

I just called the status buffer from magit on a repo. It was 23 calls to git, mostly for rev-parse. The status buffer appeared instantaneously on a decade-old laptop.

Whatever is causing the slowness you're seeing, I don't think it's just because of the number of calls. It's probably the slowness of one or two specific commands, perhaps due to repo size.

Well, I definitely notice the difference between using magit on Windows vs magit in WSL (on the same box).

Seems like there's something going on in the windows world.

Are you testing on Windows though? I am specifically talking about Windows being the (biggest) problem with this architecture. It is very expensive to create new processes on Windows versus Unix (threads are cheaper on Windows though).

Another commenter said that they also experienced slowdowns on macOS, so I thought the OS actually didn't matter much on this, but based on disgruntledphd2's comment, I guess it does.

Try opening the status buffer on a project with 50+ submodules. On microsoft Windows. Prepare to wait over 1 minute.

or when you are in the middle of a very large merge.

Reply on news.ycombinator.com