I definitely notice an EDR tax on macOS generally, but I haven't noticed Emacs having issues specifically. It's usually certain I/O operations like Git or tarball extraction that become slow.
I notice it on macOS, which I use for work. I use Linux personally but no EDR there :)
There are just so many little operations that cause stuttering on macOS with an unfortunately over-eager crowdstrike configuration. Magit is the worst offender but it causes paper cuts all over :(
So, on Mac there are two main problems - displaying and fork/exec.
Rendering on Mac is slower because NS port display backend just sucks. Emacs's redisplay emits many small drawing operations per frame - one per glyph run, cursor, or fringe bitmap. X11/cairo and pgtk on Linux batch those very efficiently - Cocoa has nothing comparable here.
You can try installing one of the forks of Mitsuharu's port - they usually have --with-metal flag and some other improvements, but they are typically one-two versions lagging behind, and in my experience they are not always stable. In general, possibility of Emacs dying on Mac is not zero, on Linux is much more rock solid.
And then the forking problem. Emacs has a big heap, so each fork is expensive. On Mac it triggers all sorts of crap - code-signature validation, Gatekeeper/XProtect scanning, TCC checks. That's dozens of milliseconds per subprocess and Linux has no such crap to deal with - shit is just fast. Magit calls git dozens of times per refresh. Now multiply that and then you get usual complains - pestilence on poor Jonas Bernoulli: "I love Magit, but why is it so damn slow..." etc.
Here are some things that I do to mitigate:
- Do these and never touch keyboard rate settings in the UI, just do it, reboot and thank me later.
# "Set a blazingly fast keyboard repeat rate, "
defaults write NSGlobalDomain KeyRepeat -int 1
# "Set a shorter Delay until key repeat"
defaults write NSGlobalDomain InitialKeyRepeat -int 9
- I turned off Spotlight indexer completely - I don't search for files through it nor through Alfred.
sudo mdutil -a -i off
- Set `core.fsmonitor true` in gitconfig. Add `core.untrackedCache true` to go with `status.showuntrackedfiles all`, otherwise the fsmonitor win is partly eaten by the untracked scan.
- Remove sections from Magit you don't need all the time, e.g.:
;; who cares if tags not displayed in magit-refs buffer?
(remove-hook 'magit-refs-sections-hook #'magit-insert-tags)
There are some other things, but that's what I remember off the top of my head, if I recall some more, will update.
I know at least some of my slowness is crowdstrike, especially since I can A/B test non-Emacs operations with some coworkers with older machines that don't have the bad config.
Great list, thank you. I recently switched to a Macbook for work and I could feel the difference in speed whenever I used Emacs back on my desktop (Linux).
This helps a bit though magit still feels very sluggish.
Might want to check your git logs if you are using the Merge Queue feature. This afternoon, we found that Merge Queue was silently reverting changesets in the merge queue. Acknowledged by GitHub, but could be a very hard problem to debug if you aren't looking for it.
Yeah city is not fully a function of zip. ~I think state is though.~* I believe when multiple cities share a zip code USPS uses the larger one. Usually the wrong city will get delivered though, probably not guaranteed.
* correcting myself, some zip codes do cross state lines
Can't say anything about the US, but in Germany when more than one cities have the same zip code it's just not important because there is only one sorting center for all cities with the same zip and they just sort per street address.
It seems like they should be able to “overweight” newer training data. But the risk is the newer training data is going to skew more towards AI slop than older training data.
I don’t think you can do that. Or at least if you could, it would be an unintelligible version of English that would not seem much different from a programming language.
I agree with your conclusion but I don't think it'd necessarily be unintelligible. I think you can describe a program unambiguously using everyday natural language, it'd just be tediously inefficient to interpret.
To make it sensible you'd end up standardising the way you say things: words, order, etc and probably add punctuation and formatting conventions to make it easier to read.
By then you're basically just at a verbose programming language, and the last step to an actual programming language is just dropping a few filler words here and there to make it more concise while preserving the meaning.
However I think there is a misunderstanding between being "deterministic" and "unambiguous". Even C is an ambiguous programming language" but it is "deterministic" in that it behaves in the same ambiguous/undefined way under the same conditions.
The same can be achieved with LLMs too. They are "more" ambiguous of course and if someone doesn't want that, then they have to resort to exactly what you just described. But that was not the point that I was making.
I'm not sure there's any conflict with what you're saying, which I guess is that language can describe instructions which are deterministic while still being ambiguous in certain ways.
My point is just a narrower version of that: where language is completely unambiguous, it is also deterministic where interepreted in some deterministic way. In that sense plain, intelligible english can be a sort of (very verbose) programming language if you just ensure it is unambiguous which is certainly possible.
It may be that this can still be the case if it's partly ambiguous but that doesn't conflict with the narrower case.
I think we're agreed on LLMs in that they introduce non-determinism in the interpretation of even completely unambiguous instructions. So it's all thrown out as the input is only relevant in some probabilistic sense.
Here's a very simple algorithm: you tell the other person (in English) literally what key they have to press next. So you can easily have them write all the java code you want in a deterministic and reproducible way.
And yes, maybe that doesn't seem much different from a programming language which... is the point no? But it's still natural English.
I like that agent-shell just uses comint instead of a full vterm, but I find myself missing a deeper integration with claude that claude-code-ide has. Like with claude-code-ide you can define custom MCP tools that run Emacs commands.
I went by it a few weeks ago. There's a gate on the driveway, and I assume some kind of security presence. Probably no different than anyone under constant public scrutiny.
Well, is China a nation-state or a multi-national state, or essentially just a country(state)? English is my third language, so I just wonder do I miss some nuance here.
I definitely notice an EDR tax on macOS generally, but I haven't noticed Emacs having issues specifically. It's usually certain I/O operations like Git or tarball extraction that become slow.
reply