4 ms·

I liked magit on Linux, but on Windows it's so slow that it's unusable. Yes, I know it's because git is slower on Windows, but when using git CLI I don't feel t

I liked magit on Linux, but on Windows it's so slow that it's unusable. Yes, I know it's because git is slower on Windows, but when using git CLI I don't feel the speed difference, while on magit I feel like constantly waiting for it to happen. In the end, I just stick to Git CLI. It's fast enough, ergonomic enough for the basic usage, and works everywhere. I still wonder people who use multiple IDEs for multiple languages and have to fight different git plugins.

kqr 4y ago
Interesting that magit feels slower! Is it possible you're working faster in magit and that's why the commands involved feel slower?
- spit2wind 4y ago
  I've used Magit on Windows for the past several years and it is noticeablely slower than on Linux (because of the gut implementation on Windows). I completely understand someone choosing a different git front-end because of this. However, it's absolutely useable.
- rcthompson 4y ago
  I think it's just because many single Magit commands run multiple git commands behind the scenes in order to collect all the info. So any slowdown in how long it takes to run a single command is multiplied proportionally.
  - kqr 4y ago
    I'm suspicious of this explanation because the views that gather information from multiple commands can generally be configured down to a bare minimum that uses very few (sometimes just one) command. I assume they would have tested this before considering it inexplicably slower.
    - tut-urut-utut 4y ago
      I experience the same slowness on Windows by using bare magit without any customisation. Can you point to some resources about customisations that could make it fast?
      - kqr 4y ago
        Couple of references that helped me (though for transparency this was a few years ago): https://magit.vc/manual/magit/Status-Sections.html https://magit.vc/manual/magit/Status-Sections.html https://magit.vc/manual/magit/Performance.html https://magit.vc/manual/magit/Performance.html
- foobarbaz33 4y ago
  The problem is windows slow process spawning. Magit spawns a lot of processes to achieve it's displays and interactivity. It is a real problem. If you don't believe windows process spawingin is slow, try this: clone a git repo with 100+ submodules to your windows box. Now enjoy a nice long coffee break anytime you interact with git. And 5 coffee breaks anytime you interact with git via magit.
  - pmoriarty 4y ago
    "The problem is windows slow process spawning. Magit spawns a lot of processes to achieve it's displays and interactivity. It is a real problem" This should be potentially be solvable by using libgit2 instead of spawning a bunch of processes. There has been ongoing work to integrate libgit2 into Magit, but I don't know it's current status, nor whether that integration has made it on to Windows yet.
- miroljub 4y ago
  No, it's just slow. Every command triggers 1 to 2 seconds waiting. It's enough to break any workflow or any desire to use it. Git command line responds in 100 to 200 ms, which is not a noticeable delay. Is it because of slow git process spawning on Windows, or because magit needs multiple git command invocation to perform an action, or is it "only" slow refresh, I don't know. And honestly, I don't care. It's a chicken and egg problem. It's too slow, so I don't bother to learn it. And since I didn't learn it, I don't see any benefit in using it that could justify hours or even days of digging for performance tweaks and tricks.
johanvts 4y ago
I was really bothered by this but in the end I found that the slowness was due to conflict resolution when calling git branch. I can find the details if you want, but once I switched the default magit “git branch” call to something dumber it was fast on windows too. Edit: found my PR. Give it a try, worked wonders for my magit on windows experience https://github.com/magit/magit/pull/4717 https://github.com/magit/magit/pull/4717
- dleslie 4y ago
  Wow, I have been wanting a fix for this for years. Magit is unusable for me on windows, which is where most of my dev work is. Disappointing that your PR was closed without comment.
  - School-Cotton 4y ago
    It wasn’t closed without comment, there is a long and detailed comment explaining why the maintainers disagreed with the approach.
    - dleslie 4y ago
      Which was replied to. Then the reply was ignored.
  - johanvts 4y ago
    It would be interesting to know if this fix works for others. It would be a shame if a minor change like this is holding back a lot of windows users.
mplanchard 4y ago
Sounds like the kind of thing the developer could potentially find ways to address if they were well-funded!
- throwawaysalome 4y ago
  As near as I can tell, the guy works on emacs full-time. He's also not particularly good or clever. With the kind of money he can get through charity, there's no way he could hire the necessary Windows expertise. For one thing, he'd probably need to rework Emacs itself at the w32 level.

kqr 4y ago

Interesting that magit feels slower! Is it possible you're working faster in magit and that's why the commands involved feel slower?

spit2wind 4y ago
I've used Magit on Windows for the past several years and it is noticeablely slower than on Linux (because of the gut implementation on Windows). I completely understand someone choosing a different git front-end because of this. However, it's absolutely useable.
rcthompson 4y ago
I think it's just because many single Magit commands run multiple git commands behind the scenes in order to collect all the info. So any slowdown in how long it takes to run a single command is multiplied proportionally.
- kqr 4y ago
  I'm suspicious of this explanation because the views that gather information from multiple commands can generally be configured down to a bare minimum that uses very few (sometimes just one) command. I assume they would have tested this before considering it inexplicably slower.
  - tut-urut-utut 4y ago
    I experience the same slowness on Windows by using bare magit without any customisation. Can you point to some resources about customisations that could make it fast?
    - kqr 4y ago
      Couple of references that helped me (though for transparency this was a few years ago): https://magit.vc/manual/magit/Status-Sections.html https://magit.vc/manual/magit/Status-Sections.html https://magit.vc/manual/magit/Performance.html https://magit.vc/manual/magit/Performance.html
foobarbaz33 4y ago
The problem is windows slow process spawning. Magit spawns a lot of processes to achieve it's displays and interactivity. It is a real problem. If you don't believe windows process spawingin is slow, try this: clone a git repo with 100+ submodules to your windows box. Now enjoy a nice long coffee break anytime you interact with git. And 5 coffee breaks anytime you interact with git via magit.
- pmoriarty 4y ago
  "The problem is windows slow process spawning. Magit spawns a lot of processes to achieve it's displays and interactivity. It is a real problem" This should be potentially be solvable by using libgit2 instead of spawning a bunch of processes. There has been ongoing work to integrate libgit2 into Magit, but I don't know it's current status, nor whether that integration has made it on to Windows yet.
miroljub 4y ago
No, it's just slow. Every command triggers 1 to 2 seconds waiting. It's enough to break any workflow or any desire to use it. Git command line responds in 100 to 200 ms, which is not a noticeable delay. Is it because of slow git process spawning on Windows, or because magit needs multiple git command invocation to perform an action, or is it "only" slow refresh, I don't know. And honestly, I don't care. It's a chicken and egg problem. It's too slow, so I don't bother to learn it. And since I didn't learn it, I don't see any benefit in using it that could justify hours or even days of digging for performance tweaks and tricks.

johanvts 4y ago

I was really bothered by this but in the end I found that the slowness was due to conflict resolution when calling git branch. I can find the details if you want, but once I switched the default magit “git branch” call to something dumber it was fast on windows too. Edit: found my PR. Give it a try, worked wonders for my magit on windows experience https://github.com/magit/magit/pull/4717 https://github.com/magit/magit/pull/4717

dleslie 4y ago
Wow, I have been wanting a fix for this for years. Magit is unusable for me on windows, which is where most of my dev work is. Disappointing that your PR was closed without comment.
- School-Cotton 4y ago
  It wasn’t closed without comment, there is a long and detailed comment explaining why the maintainers disagreed with the approach.
  - dleslie 4y ago
    Which was replied to. Then the reply was ignored.
- johanvts 4y ago
  It would be interesting to know if this fix works for others. It would be a shame if a minor change like this is holding back a lot of windows users.

mplanchard 4y ago

Sounds like the kind of thing the developer could potentially find ways to address if they were well-funded!

throwawaysalome 4y ago
As near as I can tell, the guy works on emacs full-time. He's also not particularly good or clever. With the kind of money he can get through charity, there's no way he could hire the necessary Windows expertise. For one thing, he'd probably need to rework Emacs itself at the w32 level.