consult-grep (with ripgrep or ugrep) is slower than counsel-rg

[NightMachinery]

counsel-rg is much faster than consult. In fact, counsel-rg mostly feels realtime to me (especially when the query has more than around 10 characters)(without the consult-async-split-style hack), while consult is very slow. Typing a character takes around a second to update the result on an M2 Macbook.

(counsel-rg query dir args (or prompt "> "))

(consult--grep
       (or prompt engine)
       #'consult--ripgrep-make-builder
       dir
       query)

I have used consult with ugrep as well, and that also has this problem. This makes me believe that the bottleneck is with consult itself.

Perhaps using --null is expensive?

[minad]

Consult update delays can be adjusted with consult-async-* variables. It could be that you perceive Consult as slower since it doesn't restart the search as often.

For a meaningful comparison more information is needed and a recipe based on emacs -Q. Did you try to capture a profile? See https://github.com/minad/consult?tab=readme-ov-file#bug-reports.

[oantolin]

I haven't tried it. I think ripgrep didn't exist when I was an Ivy user (though I may be misremembering). To me the consult async search commands feel pretty fast, so I'm not sure I'd be able to tell the difference between them and a faster command. But you can definitely mix and match, using some consult commands and some counsel commands.

[minad]

@NightMachinery

The delay of consult--grep (which is indeed what I meant by consult-rg, as seen in my first post's code blocks) is not too bad if one hasn't seen that better is possible. The delay is also not much worse when searching a very big directory/project. But in a medium-sized directory, counsel-rg is almost instant, while consult--grep has a noticeable delay.

If you reduce the delays, setting them to smaller values, consult-ripgrep and counsel-rg should be equally fast. Can you confirm this? The Consult defaults are chosen such that the search is not unnecessarily restarted often and works efficiently on large projects.

If you see a significant difference, please capture profiles such that we can investigate potential bottlenecks.

[NightMachinery]

@minad No, even with

  (setq consult-async-min-input 3)
  (setq consult-async-refresh-delay 0.01)
  (setq consult-async-input-throttle 0)
  (setq consult-async-input-debounce 0)

counsel-rg is faster. consult still has a delay, while counsel-rg isn't that different from native emacs (sth like consult-line, though of course not that good).

I can capture profiles, but my guess is that there is no performance problem; the way consult uses timers to refresh is probably just worse than whatever counsel uses.

I tried capturing a profile, but I got this weird error:

CPU profiler stopped
Assertion failed: (>= match imatch) [2 times]

[minad]

Thanks!

I gave consult--async-refresh-timer another critical look and the implementation was indeed not good, since it repeated the refreshing at a certain interval.

I don't recall exactly why I implemented this in that way, but I suspect that I wanted to avoid unnecessary timer restarts and allocations. The idea was to only set the refresh variable when new candidates come in, and then refresh the display from the timer if the refresh variable is set. For large delays this works well, but for small delays the cost of unnecessarily executing the timer repeatedly dominates.

I have now replaced this with an optimized implementation where the timer is restarted when necessary and not repeated (6dc9f33). I still avoid timer allocations (3013e85). With these changes the aggressive settings work much better, including a refresh delay of 0.

(setq consult-async-input-debounce 0
      consult-async-input-throttle 0
      consult-async-refresh-delay 0)

(I still don't recommend such settings, since we win nothing when we execute the search before we've finished a little bit of typing.)

[NightMachinery]

Thanks, the new commit is indeed great and snappy. Do you recommend setting consult-async-refresh-delay to 0 or something a bit higher? I don't care at all about battery/energy usage, I just want the best performance.

[minad]

Well, I recommend the default settings.

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.

But to be clear, 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.

[NightMachinery]

I use gcmh-idle-delay, and I don't GC at all during the consult call.

(setq
 ;; beware large gc thresholds: https://emacs.stackexchange.com/questions/5351/optimizing-font-lock-performance
 ;; beware small thresholds as well -_-: emacs breaks as company continuously fills up its memory and gc throws them out
 ;;
 gcmh-idle-delay 15
 gcmh-high-cons-threshold (* 32 1024 1024)
 ;; the first number will be in megabytes. doom's default was 16mb
;;;
 ;; one of these two should be nil
 gcmh-verbose nil
 garbage-collection-messages t
 )

[minad]

I expected that you use gcmh. I don't recommend gcmh and don't consider it a good idea to just fill memory up. We can do better than that simply by not creating too much garbage in the first place. Hopefully Emacs will get a better gc at some point, but for now we have to live with what we have and that's why the defaults are like they are.

The problem with gcmh is that it will lead to very long pauses from time to time. This would hurt my setup a lot, since I also use EXWM. Of course I use increased GC settings, since the Emacs defaults seem as if they come from the 90s, but I am not radical enough to disable the GC completely for a long period of time. My setup does not suffer from long GC pauses and is overall pretty responsive. Note that commands like consult-ripgrep temporarily raise the gc limit and the process pipe limit for better throughput.

EDIT: I just saw that your gcmh-high-cons-threshold is pretty small, of the order of my own gc-cons-threshold. With such settings you certainly don't profit from the "magic hack" but you will regularly see GCs during normal usage. These GCs will be sufficiently fast since your heap doesn't grow like crazy, but then my argument from above applies - we want to reduce memory allocations to avoid increased GC activity. In other words, either one uses the "magic hack" where wasting memory is free until it is not, or we have to save allocations to not overload our old and trusted non-incremental, non-parallel and non-concurrent GC.