reddit / emacs
Magit performance on M1 Mac
actionshrimp · 2022-12-17 15:00
I've recently started using an M1 Mac for work, having previously used linux, and am finding the performance of magit to be extremely slow.
I'm wondering if it's some oddity of my setup in particular, although my colleague notices the same issues.
We are both using emacs-mac, his installed from homebrew via the railwaycat formula, mine built from the emacs-28.1-mac-9.1 tag using nix. I understand that this has a perf fix after a MacOS change to \`vfork\` last year.
Some examples of the kind of performance issues we're seeing: it takes a few seconds to open the git status buffer (even on very small projects with little git history - longer on larger projects), and going through a diff to stage selected hunks seems to take a second or two for each one, which seems very high and is frustrating when you have a lot of changes to look through when trying to create a logical commit. On linux all these operations felt more or less instantaneous.
I've seen suggestions for improving performance by disabling parts of the status screen etc., but I'd rather avoid doing this if possible, and not sure if this would help with peformance when staging something. The fundamental issue seems to be around slowness when emacs creates processes, rather than anything specific to magit, I just notice it with magit in particular as it creates a lot of git processes.
I just wondered if this was considered 'normal' on MacOS and everyone just puts up with it, in which case I'll have to learn to live with it too. But I'm a bit baffled by the fact that there just seems to be very little discussion online about the problem.
If anyone has any insight, even if it's just to share that they see the same behaviour so I no longer feel like I'm going insane, it would be much appreciated :-)
__nautilus__ · 2022-12-17 15:35
Have you checked out all the recs here? https://magit.vc/manual/magit/Performance.html
hmeh922 · 2022-12-17 15:56
I have an M1 and magit is fast still. I use emacs-plus@29 though.
phanboy4 · 2022-12-17 16:16
No perf issues on M1 Macs for me.
Either a config issue, an issue with your Git version, or an issue with your Emacs build.
kkvi115 · 2022-12-17 16:28
I’m have issues with emacs plus 29. But it is not as fast as emacs on my linux box.
GAMEWARRIOR010 · 2022-12-17 17:09
I have had problems with Emacs Mac being slow I recommend trying to use Emacs Plus.
actionshrimp · 2022-12-17 17:17
Thanks, will give emacs-plus a go!
actionshrimp · 2022-12-17 17:18
Ok, good to hear - I'll keep trying to figure out the issue then. Thanks!
actionshrimp · 2022-12-17 17:18
Ok, people seem to recommend emacs plus, so I think I'll give that a try. Thanks!
actionshrimp · 2022-12-17 17:18
Ok great, definitely gonna give emacs plus a go. Thanks for the recommendation :)
actionshrimp · 2022-12-17 17:19
Yeah - I've had a read, was hoping to avoid having to turn off features if I could avoid it. The slowness is so extreme it feels like it must be something more fundamental. But I might have to resort to some of these if nothing else works.
cellular--automaton · 2022-12-17 17:39
Yup. emacs-plus@28 and it works ok. I do have a question though: has anyone gotten hunspell to play nice with emacs on a mac ?
hmelman · 2022-12-17 18:10
If you're using `magit-todos`, `(setq magit-todos-branch-list nil)`
__nautilus__ · 2022-12-17 18:10
There used to be a trick on Mac where directly specifying the git executable sped things up considerably, i.e. setting it to /opt/homebrew/bin/git or whatever instead of just git. I don’t see this advice anywhere now, so it may no longer be relevant, but it’s something I used to do when I was using a Mac.
EnvironmentalEar860 · 2022-12-17 18:35
I guess I've tried at some point to make it work but then I installed `aspell` which works great.
kkvi115 · 2022-12-17 19:12
let us know how it goes.
cellular--automaton · 2022-12-17 19:33
Gotcha, thanks. The reason I have been using hunspell is that it allows multi-language dictionaries - my distro [emacs-groundup](https://gitlab.com/public-repositories/emacs-groundup) uses this and I feel too lazy (and busy) to go tinkering with the config right now :D
I remember when I set things up, aspell did not allow multi-language. I wonder if things have changed.
actionshrimp · 2022-12-17 19:39
Ah yeah I remember that too from using intel MacOS a few years back - I think it was to do with following symlinks being slow or something like that. I did try this but no luck unfortunately.
super-linux-nerd · 2022-12-17 19:53
Same. I also use magit extensively over TRAMP and it works like a champ
actionshrimp · 2022-12-17 23:30
So with emacs-plus I saw pretty similar performance to be honest. Then thought it was AV software for a while, no luck. When I turned on \`magit-toggle-verbose-refresh\` I got this:
```
magit-insert-error-header 6e-06
magit-insert-diff-filter-header 2.5e-05
magit-insert-head-branch-header 0.062119 !!
magit-insert-upstream-branch-header 0.062515 !!
magit-insert-push-branch-header 0.02853 !
magit-insert-tags-header 0.06319 !!
magit-insert-status-headers 0.246637 !!
magit-insert-merge-log 0.031908 !!
magit-insert-rebase-sequence 7.2e-05
magit-insert-am-sequence 3e-05
magit-insert-sequencer-sequence 9.9e-05
magit-insert-bisect-output 3.5e-05
magit-insert-bisect-rest 6e-06
magit-insert-bisect-log 6e-06
magit-insert-untracked-files 0.307373 !!
magit-insert-unstaged-changes 0.281099 !!
magit-insert-staged-changes 0.063509 !!
magit-insert-stashes 0.02874 !
magit-insert-unpushed-to-pushremote 4.2e-05
magit-insert-unpushed-to-upstream-or-recent 0.182833 !!
magit-insert-unpulled-from-pushremote 1e-06
magit-insert-unpulled-from-upstream 0.033298 !!
forge-insert-pullreqs 0.031442 !!
forge-insert-issues 3e-06
```
and as none of the slow git features were particularly appealing to turn off I tried to figure out what else was going on - but it seems to be git itself indeed.
I tried \`(setq magit-git-executable "/usr/bin/git")\` to use the macos git (by default my path selects the nix installed version of git), but that didnt seem to make any difference.
However, installing \`git\` from homebrew and using \`(setq magit-git-executable "/opt/homebrew/bin/git")\` does seem to yield a fairly significant perf improvement - the slow sections drop from \~0.3s to a mere \~0.2s (300ms total improvement helps a fair bit indeed). Thanks to u/**nautilus** for the reminder here, I initially mistakenly thought it was to do with symlink/path lookup, but there definitely seems to be a big difference in the selected version of git itself.
paretoOptimalDev · 2022-12-18 00:47
I've always found Mac to be slower than linux for emacs and open source software.
I honestly don't think it'll change unless Mac becomes the default for open source developers.
actionshrimp · 2022-12-18 11:32
Hmm strangely the difference between the nixpkgs version of git and the homebrew version of git doesn't seem so noticeable today.
Although in fact, after restarting the machine this morning, the timings for \`magit-insert-untracked-files\` and \`magit-insert-unstaged-files\` have dropped down to more like 0.1s, using the original version of git that gave me the timings listed above (and on the same repo).
Very confused now! It seems like something is getting clogged up as the machine is left on and causing git to get slower and slower, and that it is reset by rebooting - will continue to keep an eye on it.
r0flcopt3r · 2022-12-18 13:01
I had serious performance issues with magit on LARGE mono repos. The problem was disk indexing. macOS would reindex the drive whenever big file system changes happened, like switching branches... Disabling indexing did the trick for me.
My git repos are in a separate partition that also has case sensitivity enabled. So I was able to turn indexing off on this specific partition, and have everything work elsewhere
actionshrimp · 2022-12-18 13:22
Ah interesting! I was literally just noticing a big perf hit when I had an incremental build task running in the background, so I wonder if it could be disk indexing analysing the files as the build runs. Will definitely have a go at disabling this - thanks for the suggestion.