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

[Dmitry Gutov]

Hi Gregory,

On 07.03.2021 00:47, Gregory Heytings wrote:

> I just did a number of timing tests.  The timings were done in a shell, 
> on a fresh clone of the Emacs repository, which contains ~5000 files, 
> and in which one searches for the 43 occurrences of "expose_frame".
>
> The timings are (in seconds):
>
> with GNU grep (version 3.6):
>
> 0.124 | "find  -name '.?*' -prune -o -type f -print | xargs grep -i 
> -snHE expose_frame"
> 0.178 | "find  -name '.?*' -prune -o -type f -print | xargs grep -i 
> -snobHE '.{0,50}expose_frame.{0,50}'"
> 0.253 | "find  -name '.?*' -prune -o -type f -print | xargs grep -i 
> -snobHE '.{0,80}expose_frame.{0,80}'"
> 0.325 | "find  -name '.?*' -prune -o -type f -print | xargs grep -i 
> -snobHE '.{0,100}expose_frame.{0,100}'"
>
> with ripgrep (version 12.1.1):
>
> 0.045 | "find  -name '.?*' -prune -o -type f -print | xargs rg -i -nH 
> --no-messages expose_frame"
> 0.079 | "find  -name '.?*' -prune -o -type f -print | xargs rg -i -nobH 
> --no-messages '.{0,50}expose_frame.{0,50}'"
> 0.109 | "find  -name '.?*' -prune -o -type f -print | xargs rg -i -nobH 
> --no-messages '.{0,80}expose_frame.{0,80}'"
> 0.113 | "find  -name '.?*' -prune -o -type f -print | xargs rg -i -nobH 
> --no-messages '.{0,100}expose_frame.{0,100}'"
>
> It seems that a reasonable compromise is a context of 80 characters, 
> which is only two times slower than a string search with both GNU grep 
> and ripgrep, and still very fast.

'find' is rarely the fastest way to list all the files in the project. 
Have you timed it alone?

'git ls-files' is usually much faster, and that's what 'project-files' 
uses under the covers. So if you redo your test with 
'project-find-regexp' as I suggested, you might discover a different 
slowdown multiplier.

> (FTR, I also compared these performances with ack, ag and git grep.  To 
> my surprise, they are much slower: ack is about three times slower than 
> GNU grep on a string search, ag is a bit slower than GNU grep on string 
> searches but much much slower on regexp searches, and git grep is a bit 
> faster than ripgrep (and GNU grep) on string searches but again much 
> much slower on regexp searches.)

ripgrep is generally the best all-arounder these days, though it might 
be slower in certain odd cases.

'git grep' is not a real option because it uses Git's list of tracked 
files directly, and we can't really do that. And that skews the comparisons.