Why Emacs Consult async searches feel slow and how to speed them up(jamescherti.com) |
Why Emacs Consult async searches feel slow and how to speed them up(jamescherti.com) |
You can do it in the background with:
https://pavpanchekha.com/blog/emacs-keylogger.html
and periodically update the latency parameters to be just over your natural typing speed.
I've got an emacs uptime measured in years, so I have no idea what you're talking about, but I'm happy that you're happy.
You "chose to use an editor", pfff... bro, my key-switches are dying of laughing.
Corporate EDR BS.
I thought Emacs was terrible to use until I realized it was extremely fast on my home computer. All the pauses that EDR does combined with Emacs mostly single threadedness is a bummer. I still daily drive it now for my IDE at work because it's workflows work better for me than others, but it is such a bummer.
If just logging filesystem interactions and whatnot for future upload is also slow then you're hosed, but at one place I worked every application too an extra several seconds to start up for some sort of remote program inspection, which is fine till the application is git, grep, or cd.
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.
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 :(
It still pegs the CPU frequently. It is extremely irritating to open the Activity Monitor and see it at the top.
What good is it in a Mac anyway? This is a not a virus ridden OS like back in the day Windows.
On Mac, I combined it with Flameshot to select a region, and Hammerspoon that watches the clipboard, so it always automatically OCRs anything I screenshot and pops into a buffer. On Linux I haven't spend time figuring out how to hook it up, so after the screenshot, I just have to manually call the command.
¹ https://github.com/agzam/.emacs.d/blob/main/modules/writing/...
> no focus-wandering, no lollygagging
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
defaults write org.gnu.Emacs NSAppSleepDisabled -bool YES
sudo mdutil -a -i off
- 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)
This helps a bit though magit still feels very sluggish.
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.