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: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 46859 <at> debbugs.gnu.org
Subject: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el
Date: Sun, 7 Mar 2021 05:08:42 +0200

On 07.03.2021 01:24, Gregory Heytings wrote:
> 
>>
>> '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.
>>
> 
> I don't see a big difference: find takes 0.006 s, git ls-files 0.002 s. 
> Okay, that's three times slower, but those four milliseconds are not the 
> bottleneck here.  I just ran some of the timing tests again, and they 
> are about ten milliseconds faster with git ls-files, which is not a huge 
> difference.  (Of course I do not object to the use of git ls-files.)

Sounds like you're testing the case of a project with not many files 
which compensate for their number in (larger) size.

That would indeed be sweet sport for using find in this scenario, so 
please consider that objection withdrawn.

>> So if you redo your test with 'project-find-regexp' as I suggested, 
>> you might discover a different slowdown multiplier.
>>
> 
> I wanted to first time these things outside of Emacs, it seems to me 
> that it's a more objective comparison.

Very well.

But testing inside Emacs is important, too. 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.

Emacs's overhead could alter that picture, however.

Previous Next

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