GNU bug report logs - #66117
30.0.50; `find-buffer-visiting' is slow when opening large number of buffers

Previous Next

Full log

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 66117 <at> debbugs.gnu.org
Subject: Re: bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening
 large number of buffers
Date: Wed, 4 Oct 2023 14:46:23 +0300

On 04/10/2023 13:58, Ihor Radchenko wrote:
> Dmitry Gutov<dmitry <at> gutov.dev>  writes:
> 
>>> Would it be possible to implement some kind of caching mechanism to be
>>> used by `find-buffer-visiting'?
>> I'm guessing you Cc'd me because of an existing comment inside xref.el?
>> As you can see I decided not to use this function there, but even
>> get-file-buffer wasn't as fast as I would've wanted, so there's a
>> quick-and-dirty caching solution for sequential lookups (which assumes
>> that the same file would be looked up multiple times in a row).
> It looks like my example is quite different from yours.
> Do you have a reproducer demonstrating `get-file-buffer' being slow?

I retested, and it seems most people here won't be impressed by my 
example. Anyway:

1. Call (benchmark-run 1 (project-find-regexp "emacs") in an Emacs repo 
checkout.
2. Change xref--collect-matches to call get-file-buffer instead of 
xref--find-file-buffer (which does some caching). 'M-x 
byte-compile-file', (load "xref.elc"), and run the benchmark again.

What I get here, is 3.60s vs 5.03.

It's a 1.40s difference over ~95000 calls, though (this is how many 
matches are produced). Which is meaningful for my case, but probably not 
for yours.

Previous Next

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