bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el

[Gregory Heytings <gregory@heytings.org>]

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]


>> I don't see a big difference: find takes 0.006 s, git ls-files 0.002 s. 
>> Okay, that's three times slower, but those four milliseconds are not 
>> the bottleneck here.  I just ran some of the timing tests again, and 
>> they are about ten milliseconds faster with git ls-files, which is not 
>> a huge difference.  (Of course I do not object to the use of git 
>> ls-files.)
>
> Sounds like you're testing the case of a project with not many files 
> which compensate for their number in (larger) size.
>

As I said, my tests are performed on a fresly cloned copy of the Emacs 
repository (~5000 files).  It's not a huge project, but it's not a small 
one either.

>>> So if you redo your test with 'project-find-regexp' as I suggested, 
>>> you might discover a different slowdown multiplier.
>> 
>> I wanted to first time these things outside of Emacs, it seems to me 
>> that it's a more objective comparison.
>
> Very well.
>
> But testing inside Emacs is important, too.
>

Yes.  It is important to test at each step of the pipe; step N can't 
become faster than step N-1.

>
> Because with the results you shown as of yet, the proposed alternative 
> is twice as slow as the existing code in the average case. Is that 
> right? I wouldn't like searches that take 200ms now take 400ms.
>

Of course you can't get a benefit without paying a certain price.  The 
tests show that, on the Emacs repository, a search takes 250 ms instead of 
125 ms with GNU grep, and 100 ms instead of 50 ms with ripgrep.  IMO that 
price is not too high, especially not for a user dialog (I don't see how a 
user could be annoyed, or even notice, that something takes 250 ms instead 
of 125 ms), but it's just my opinion.

>
> Emacs's overhead could alter that picture, however.
>

Indeed.