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: Dmitry Gutov
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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.





reply via email to

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