4 ms·
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
by grumpyprole 5y ago
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 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.
- deleted 5y ago[deleted]
- jolmg 5y agoI 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.
- disgruntledphd2 5y agoWell, 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.
- grumpyprole 5y agoAre 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).
- jolmg 5y agoAnother 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.
- foobarbaz33 5y agoTry opening the status buffer on a project with 50+ submodules. On microsoft Windows. Prepare to wait over 1 minute.
- gpderetta 5y agoor when you are in the middle of a very large merge.