Why Emacs Consult async searches feel slow and how to speed them up
summary
The Consult package for Emacs uses debounce and throttle delays to manage asynchronous search processes, which can make the UI feel sluggish compared to other packages. Users can reduce these delays to achieve lower latency and a more responsive feedback loop. However, this speed increase comes at the cost of higher CPU usage and faster battery drain. Finding the right balance depends on the user's hardware and typing speed.
key points
- Debouncing waits for a period of inactivity after the last keystroke before starting a search, preventing redundant background tasks.
- Throttling enforces a strict maximum frequency for starting asynchronous processes, regardless of how fast the user types.
- The refresh delay determines how often the completion UI updates with new results, though frequent updates increase the cost of Emacs redisplay.
who should read it
Emacs users who utilize the Consult package and want to optimize the responsiveness of their asynchronous search commands.
discussion skeptical
consensus
Users agree that Emacs performance on macOS is significantly degraded by security software like CrowdStrike and Microsoft Defender, which introduce latency during I/O and subprocess forks. This is particularly evident in Magit, where frequent git calls trigger expensive system checks. While some users suggest disabling internet access or adding exclusions, the general sentiment is frustration toward corporate EDR overhead.
top insight
The perceived slowness of Emacs on macOS is a combination of inefficient rendering via the NS port and the high cost of forking large heaps, which triggers Gatekeeper and XProtect scans. Mitigating this requires system-level tweaks, such as disabling App Nap, turning off Spotlight indexing, and using git's fsmonitor to reduce the number of filesystem calls.
Generated by an LLM from the article and thread. Check the sources before relying on it.