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

Previous Next

Full log

Message #176 received at 46859 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 46859 <at> debbugs.gnu.org
Subject: Re: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in
 xref.el
Date: Sun, 7 Mar 2021 01:00:39 +0200

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.

Previous Next

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