[grumpyprole]

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.

[jolmg]

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.

[foobarbaz33]

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

[gpderetta]

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

[grumpyprole]

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).

[jolmg]

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.

[disgruntledphd2]

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.