Maybe there is an option somewhere in magit to not show diff completely for files with specific file extension or something.
1. Clone <https://chromium.googlesource.com/chromium/src>.
2. Navigate to this directory in Emacs dired.
3. Run magit-status.
4. Observe how long it takes for Emacs to become responsive again. For me it's 28 seconds, while running git status in the terminal takes 6 seconds.
$ git clone https://chromium.googlesource.com/chromium/src Cloning into 'src'... remote: Sending approximately 36.75 GiB ...
So it is not at all surprising, that things get laggy, when you run them on 36.75 GiB. You probably do not want to check out everything at once.
> You probably do not want to check out everything at once.
I do, if I want to compile the project, browse its history and push commits, which is what I'm paid for.
Consider the extra work and data structure representation in the magit buffers in Emacs, that is not done on command line. For example magit makes diffs and chunks of diffs neatly foldable. It also colors things in that foldable content. It also has context knowledge, when you move your point over some diff or chunk and then run another command / Emacs procedure. It probably does some more things I cannot think of right now. Somewhere there is a cost associated with having more than a simple stream of text that is output exactly once, like on command line.
Is it still 5 times as laggy, once the initial magit-status is calculated? Does it recalculate all the things, when you stage a chunk of a diff, or does it profit from having a data representation of the diff in memory?
Sublime Merge is pretty laggy, but in a different way, that's more acceptable to me: it is asynchronous, so when I order Sublime Merge to perform an action on the git repo, I can still interact with the GUI, browsing the list of commits etc.
With Emacs and Magit the problem is that everything you do in Magit blocks the whole Emacs until Magit completes its work. Running magit-status means I can't type anothing in any Emacs buffer, issue Emacs commands, scroll, read through any Emacs buffer etc. for 28 seconds.
Even though GUIs often do more than CLI tools, they actually have more potential to be faster than CLI tools, because they can be asynchronous, whereas CLIs are completely blocking, running in a one-command-at-a-time mode. One example where GUIs are more efficient than CLIs are debuggers. Which demonstrates it can be done.
I see two main issues with Magit when it comes to performance:
1. It's blocking, not asynchronous.
2. It's written in ELisp, which is a fractal of bad decisions performance-wise.
> Is it still 5 times as laggy, once the initial magit-status is calculated?
It is.