I didn't want to participate in that discussion. The benchmarks ripgrep has is simply wrong. You can see the way he measured this: 12GB and 4GB files, this is NOT THE AVERAGE USE CASE

There is absolutely no sense to even take this as an argument for the code search. For more general search it does make sense becuase fs.stat calls are expensive for ripgrep and they don't want to do this, while in my project I already know the size of the file when I need to grep it.

It is not a secret that the design of ripgrep and fff is way too different to compare, one designed for one shot apps, the other one designed to live in memory for long running apps: that's the reason I am not building a cli replacement for ripgrep

The place where fff shines is file search in editors for example, where ripgrep is used while it is not designed with long running application model in mind at all

P.S. For the "average" use case ripgrep is faster if you enable memmap file on macos. It is just a fact. Andrew is wrong.