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

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Gregory,

On 07.03.2021 10:13, Gregory Heytings wrote:

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

Hmm, both 'find' and 'git ls-files' take a little more than that on the 
Emacs repository.

But my impression on 'find' is skewed because it performs much worse as 
soon as we try to ignore files with it. When no predicates are used, 
it's fairly fast and shouldn't be too much of a problem in this comparison.

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

Well, yes and no. I have just improved performance in the case under 
discussion significantly with no loss in functionality or measurable 
loss of performance in "normal" cases.

I don't mean to be discouraging, but the benefits should be pretty great 
for us to pay the price of 2x slower matching speed.

And it wouldn't be necessary of Grep had an option to limit the 
displayed context around the match without us mucking with the regexp. 
It would solve the issue of incorrect byte position, too.

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

The bigger the project, the longer it will take. Emacs is not the 
biggest project size we want to support.