bug#50733: 28.0.1; project-find-regexp can block Emacs for a long time

[Dmitry Gutov]

On 24.09.2021 17:20, Eli Zaretskii wrote:

> More to the point: are you saying that a tool that returns more
> matches is necessarily better?  That'd fly in the face of our
> switching to the Xref package, whose explicit goal was to provide
> _fewer_ matches, the ones that matter.  Look closer at those matches
> which gid "missed", and you will see why it didn't show them to you.

Xref's find-definition and find-references indeed try to be more 
precise. But that's only for identifier searches.

> Oh, and if ripgrep finds only 45 matches, then something is wrong with
> it, because there are actually no less than 119 literal matches for
> O_CREAT in the tree (not counting many binary files that also match).
> So by this measure, ripgrep is also not the right tool for the job.

I'm guessing the remaining entries are somewhere in gitignore-d files?

> > Five seconds to scan the whole Emacs trunk is IMO not fast enough (ripgrep
> > does it in < 0.2 seconds).
>
> Those 5 sec are invested only when needed, while the time it takes
> Grep/ripgrep to scan the files is invested every search.  Do this
> enough times, and you paid too much time.

FWIW, (project-find-regexp "O_CREAT") takes about 130ms here.

That's close to the perceptual "instant" time.