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

[Gregory Heytings]

> > 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.