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

[Eli Zaretskii]

> Date: Fri, 24 Sep 2021 21:49:35 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 50733@debbugs.gnu.org, dgutov@yandex.ru, mardani29@yahoo.es
> 
> >> Hint: read again, and look closer.  gid returns some matches in 
> >> comments, some not.  For no apparent reason.
> >
> > Of course, there is a reason, you just don't understand it
> 
> Who told you that I'm talking about myself?  FWIW, I understand the 
> reason, but it's a completely non-apparent one, that isn't documented 
> anywhere.  And it's not one that would make sense to most users.

What would you like to document about it? that sometimes false
positives do happen?  Does any other similar utility ever does
something like that in its documentation?  Dealing with false
positives is for the users of the utility, because only they know
which ones are false.

Or are you saying that having N false positive is somehow worse than
having M > N false positive, because some theoretical users might not
understand why they see some of the N false positives but not the
others?  (I say "theoretical" because evidently you didn't have a
problem understanding the reason.)

> Out of curiosity, because of your "it doesn't scale" remark, I just 
> compared the efficiency of ripgrep and idutils on the latest Linux kernel 
> tarball (1.4 GB in 78464 files):
> 
> mkid takes 31 seconds
> 
> rg O_CREAT takes 0.18 seconds
> gid O_CREAT takes 0.02 seconds
> rg O.?CREAT takes 0.18 seconds
> gid O.?CREAT takes 0.93 seconds
> rg O.*CREAT takes 0.19 seconds
> gid O.*CREAT takes 1.73 seconds
> 
> Isn't idutils the one that doesn't scale?

No.  You compare apples with oranges.

> The only case in which idutils is faster (if one does not take the time 
> that was spent to build the database into account, and if one considers 
> that it's okay to ignore some matches in comments) is a plain identifier; 
> from a user viewpoint getting an answer in 0.2 seconds on such a big code 
> base is as good as getting an answer in 0.02 seconds.  It's slower, much 
> slower in all other cases, whenever a regexp is used --- which is what 
> project-find-regexp is all about.

See what I mean?  Even when it's better, it's worse.  Perfect
reasoning.