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

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 46859 <at> debbugs.gnu.org
Subject: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el
Date: Sat, 06 Mar 2021 22:47:45 +0000

>>> Also: grepping for that kind of regexp is noticeably slower than 
>>> grepping for 'file'. Or even '.file'. Like 85ms vs 7ms slower.
>> 
>> Well, the bug report mentioned delays of 3-4 seconds on files with very 
>> long lines, so I'd guess that 85 ms is a pretty reasonable speed...
>
> We do want fast searches to remain fast, too.
>
> I got that 85ms timing when searching just one file. A project can often 
> contain thousands of files.
>

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.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.