4 ms·

My issue is not that things are laggy in this case, but that they are 5 times as laggy as the command line interface. > You probably do not want to check out e

My issue is not that things are laggy in this case, but that they are 5 times as laggy as the command line interface. > 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.

zelphirkalt 4y ago
Have you tried any GUI tool and found a less laggy one? 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?
- yakubin 4y ago
  > Have you tried any GUI tool and found a less laggy one? 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.

zelphirkalt 4y ago

Have you tried any GUI tool and found a less laggy one? 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?

yakubin 4y ago
> Have you tried any GUI tool and found a less laggy one? 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.