bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gregory Heytings
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.)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]