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

Previous Next

Package: emacs;

Reported by: Ihor Radchenko <yantar92 <at> posteo.net>

Date: Wed, 20 Sep 2023 08:53:02 UTC

Severity: minor

Found in version 30.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #100 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: Thu, 5 Oct 2023 20:14:28 +0300
On 05/10/2023 14:27, Ihor Radchenko wrote:
> Looking into `xref--find-file-buffer', all it does is memoizing the
> previous call. I think that we can easily achieve the same performance
> improvement by maintaining approximate cache for Fget_file_buffer -
> something like
> (if (and (gethash file cache)
>             (equal (buffer-local-value 'buffer-file-name (gethash ...)) file))
>    <return cached>
>   <compute and cache the result>)
> 
> Or maybe even cache the last call separately to not pay `gethash' call price.

That works for the Xref's scenario (where, when there are many matches, 
they would tend to come several per file), but I'm not sure it's a good 
caching strategy in general.

And applications that are suited for it might as well write a small 
wrapper like I did.

> 100% reliable cache is not necessary in this scenario. And not necessary
> in my scenario, as I have found via my benchmarks in another message.

IIUC a cache that keys on non-abbreviated/non-expanded filenames would 
be able to speed all that up anyway. But a more algorithmic improvement 
first would be better, of course.




This bug report was last modified 1 year and 135 days ago.

Previous Next


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