Why Emacs Consult async searches feel slow and how to speed them up? (consult-fd, consult-find, consult-grep, consult-ripgrep...) | James Cherti

Skip to primary content

James Cherti
Linux, Emacs, and Software Development

Search

Main menu
Home
Articles
Projects
About
Contact

Why Emacs Consult async searches feel slow and how to speed them up? (consult-fd, consult-find, consult-grep, consult-ripgrep...)

Share: Hacker NewsXRedditLinkedInAuthor: James Cherti
The consult Emacs package provides asynchronous search commands such as consult-fd, consult-find, consult-grep, consult-git-grep, and consult-ripgrep. For these commands, Consult does not necessarily start a new search for every change to the minibuffer input. Instead, it uses configurable debounce and throttle delays to control when asynchronous processes start, while a separate refresh delay controls how frequently asynchronous results are pushed to the completion UI.
The first time I tried Consult, I thought to myself: this feels slow compared to Counsel (I had a similar feeling about Emacs settings such as show-paren-delay). With Counsel, results updated immediately on every keystroke, while Consult seemed to hesitate for a fraction of a second before updating the list.
As it turns out, this behavior is entirely intentional. The current Consult defaults are conservative by design.
Aggressive asynchronous search
If you prefer lower latency and speed, these variables can be made more aggressive:
(setq consult-async-input-debounce 0.05
consult-async-input-throttle 0.1
consult-async-refresh-delay 0.05)
These values reduce the amount of time Consult waits before starting another asynchronous search and allow the completion UI to refresh much more frequently.
These values do not make the underlying search programs execute faster. External tools like ripgrep already use highly optimized, multi-threaded algorithms to scan files across multiple CPU cores. Instead, these variables speed up the feedback loop inside Emacs itself. They reduce the waiting period before Consult spawns the external process, and causing the Emacs UI to pull in new asynchronous data and redraw the screen at a much faster rate.
Variable: consult-async-input-debounce
(setq consult-async-input-debounce 0.05)
This setting forces Consult to wait 0.05 seconds after your last keystroke before launching an asynchronous process. Because this acts as a debounce delay rather than a fixed polling interval, every new input resets the timer. The search only executes once the full quiet period elapses.
This prevents Emacs from spinning up redundant background tasks for every intermediate character you type, which minimizes CPU overhead and keeps the UI responsive.
Variable: consult-async-input-throttle
(setq consult-async-input-throttle 0.1)
The consult-async-input-throttle variable acts as a hard rate limit for how often Consult starts asynchronous processes. With this value, a new process starts at most once every 0.1 seconds, regardless of how fast you type.
To break down the difference between the two concepts:

Debouncing is an idle timer. It waits for you to stop typing. If you keep hitting keys, the timer keeps resetting, and the search will not run until you stop typing.
Throttling is a strict speed limit. It enforces a maximum execution rate. Even if you pause just long enough between words to constantly trigger the debounce timer, the throttle ensures the system will not exceed the permitted rate.

Variable: consult-async-refresh-delay
(setq consult-async-refresh-delay 0.05)
The consult-async-refresh-delay variable controls how frequently Consult updates the completion UI with results from asynchronous commands. This value makes Consult refresh at intervals as short as 0.05 seconds when new results require an update. It does not cause Emacs to redraw continuously when there is nothing new to display.
A low refresh delay can make search results appear faster, but redisplay itself has a cost. Emacs redisplay is expensive enough that highly frequent updates can increase CPU and garbage-collection activity.
Choosing values
If you prefer asynchronous searches to feel as responsive as possible, these values offer a good balance between low input latency and resource usage. Consult responds quickly to minibuffer changes and updates the completion UI with minimal delay.
These settings are well suited to fast computers plugged into a power source. On a laptop, the aggressive process creation and continuous UI updates will keep the CPU active and drain your battery much faster than the conservative defaults. On slower computers or when searching very large projects, the default values may provide a better balance by avoiding unnecessary searches while input is still changing.
The optimal values depend on typing speed, project size, search-tool performance, power constraints, and the cost of processing and redisplaying asynchronous results in Emacs. Lowering the delays is therefore best viewed as an explicit trade-off: less input latency in exchange for more frequent asynchronous work.

Related posts:
Preventing Emacs from entering the debugger when a specific error occurs
The compile-angel Emacs package: Byte-compile and Native-compile Emacs Lisp libraries Automatically
ultisnips-mode.el - An Emacs major mode for editing Ultisnips snippet files (*.snippets files)
easysession.el: Easily persist and restore Emacs sessions (windows, tab-bar, file buffers, scratch, Dired, narrowing, indirect buffers/clones, Magit buffers...); a robust desktop.el replacement
Eglot for Python Development in Emacs: Integrating python-lsp-server (pylsp) with Linters and Formatters
Must-have Emacs Packages for Efficient Software Development and Text Editing
quick-fasd.el - Integrate Fasd for fast file and directory navigation in Emacs
Configuring Emacs Eglot for Better Performance and Latency

This entry was posted in Emacs and tagged consult, consult-fd, consult-find, consult-grep, consult-ripgrep, emacs by James Cherti. Bookmark the permalink.

One thought on “Why Emacs Consult async searches feel slow and how to speed them up? (consult-fd, consult-find, consult-grep, consult-ripgrep...)”

James Cherti on September 8, 2026 at 4:08 pm said:

Here is what Minad, Consult's author and maintainer, says about this in GitHub issue #951 of the minad/consult repository:

Regarding the best settings: "I did not determine the defaults in a scientific way based on measurements. A detailed analysis with real world measurements would certainly be appreciated. Some of the choices make sense: consult-async-input-debounce should roughly correspond to the typing speed. Furthermore consult-async-input-throttle is chosen slightly larger than the debounce delay. The third variable consult-async-refresh-delay is independent of the other two. Emacs redisplay is costly so we probably don't want to do it more than ten times per second."
Regarding the defaults: "The defaults are great because they save battery and also reduce cpu and gc load. Yes, there will be a delay after having typed something. By not starting the search too early, you can finish your input without starting a useless search, which will soon be interrupted anyway. In my opinion you don't lose much time here and the display refreshes in a less hectic and less disturbing way. One could even argue that you may win time in the end, given that Emacs is not the most performant language runtime with costly allocations. Reducing the pressure on the Emacs memory system helps us in avoiding garbage collection activity and stutter."

Reply ↓

Leave a Reply Cancel replyYour email address will not be published. Required fields are marked *Comment * Name *
Email *
Website
Save my name, email, and website in this browser for the next time I comment.

GitHub jamescherti

Mastodon @jamescherti

Reddit jamescherti

X @jamescherti

List of RSS feeds

CategoriesEmacs (RSS)
Linux (RSS)
Ansible (RSS)
Vim (RSS)
Python (RSS)
Git (RSS)
Bash (RSS)
Miscellaneous (RSS)
Popular ArticlesMust-have Emacs Packages for Efficient Software Development and Text EditingCreating and Restoring a Gzip Compressed Disk Image with dd on UNIX/Linux13 Useful GNOME Shell Extensions for a Better Desktop Experience (Available in the official Debian repositories or on the GNOME Extensions website for other distributions)minimal-emacs.d - A Customizable Emacs init.el and early-init.el for Better Defaults and Optimized StartupA Technical Guide to Compiling Emacs for Performance on Linux and Unix systemsLinux: Setting the default GDM login monitor in a multi-monitor setup using GNOME display settingsThe Definitive Guide to Code Folding in EmacsEmacs: Maintaining proper indentation in indentation-sensitive programming languagesEnabling Emacs Native Compilation and Dynamically Adjusting the Number of Elisp Files Compiled in ParallelGentoo: How to Speed Up emerge ‐‐syncEmacs: YAML file code Folding and Outliningvim-tab-bar.el - A Vim-Inspired Emacs Tab-Bar That Automatically Adapts to Any Theme

Privacy Policy Copyright (c) James Cherti
Follow James Cherti: Mastodon | List of RSS Feeds | X | GitHubAll original articles and multimedia are licensed under CC BY-SA 4.0 International.Embedded Source code is licensed under MIT.See the full License Notice for details.

The perceived slowness of asynchronous search commands within the Emacs Consult package, such as consult-fd, consult-find, consult-grep, and consult-ripgrep, stems from their intentional design choices which prioritize system efficiency over immediate feedback. Consult manages asynchronous searches by employing configurable debounce, throttle, and refresh delays to control when external processes are initiated and when results are displayed in the completion interface.

The default settings are conservative by design, aiming to reduce unnecessary processing and system load. This caution results in a noticeable hesitation when the user interacts with the minibuffer, especially when compared to systems offering immediate updates. Developers have identified three primary variables that can be adjusted to increase responsiveness, allowing for more aggressive asynchronous searching. These variables are consult-async-input-debounce, consult-async-input-throttle, and consult-async-refresh-delay.

Consult-async-input-debounce acts as an idle timer, ensuring that an asynchronous process is only launched after a specified period following the user’s last keystroke. This function prevents Emacs from initiating redundant background tasks for every intermediate character typed, thereby minimizing CPU overhead and keeping the user interface responsive by waiting for the input sequence to conclude. In contrast, consult-async-input-throttle establishes a strict rate limit on how frequently Consult is permitted to start asynchronous processes, enforcing a maximum execution rate, for instance, limiting starts to once every 0.1 seconds, regardless of typing speed. It is important to distinguish this from debouncing, which is an idle timer that waits for the user to cease input, while throttling enforces a hard maximum execution rate.

The consult-async-refresh-delay controls the frequency with which the asynchronous results are pushed to the completion UI. Setting this value lower, such as 0.05 seconds, allows the completion view to update with new results more frequently. However, the text notes that while a low refresh delay can speed up the appearance of search results, frequent updates introduce a cost because Emacs redisplaying is computationally expensive, which can increase CPU and garbage collection activity.

The goal of optimizing these settings is not to accelerate the underlying search programs themselves, as external tools like ripgrep already utilize highly optimized, multi-threaded algorithms. Instead, adjusting these variables speeds up the feedback loop within Emacs by reducing the waiting period before spawning external processes and accelerating the rate at which Emacs pulls in and redraws the asynchronous data. The optimal configuration depends on a trade-off calculation involving typing speed, project size, the performance of the search tools, power consumption constraints, and the cost associated with Emacs's screen redisplays. Lowering the delays trades input latency for more frequent asynchronous work. While some maintainers suggest that the default settings minimize resource usage by avoiding premature searches and reducing memory system pressure, others suggest that reducing these delays can yield net time savings in resource-constrained environments.