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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: dmitry <at> gutov.dev, 66117 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening
 large number of buffers
Date: Wed, 13 Dec 2023 15:25:41 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, dmitry <at> gutov.dev,
>  66117 <at> debbugs.gnu.org
> Date: Wed, 13 Dec 2023 13:06:06 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Btw, the title of this bug is about find-buffer-visiting, and AFAIR I
> > proposed to have a primitive written in C that replaces
> > find-buffer-visiting without a need to actually switch to each buffer
> > (which is what triggers the costly rebinding of buffer-local variables
> > like case-fold-search).  So why we are talking about case-fold-search
> > instead of solving the original problem?  If we want to discuss the
> > case-fold-search issue, IMO we should discuss it in a separate bug
> > report.
> 
> The bottlenecks now (after applying my patch for `find-buffer-visiting')
> are `abbreviate-file-name' and `inhibit-local-variables-p'; not the
> `find-buffer-visiting' per se (both are slow because they let-bind
> case-fold-search).

Then let's see about implementing in C of these two, or their subsets
needed by find-buffer-visiting, because case-insensitive operations in
C don't need to bind case-fold-search.

Another possibility is to rewrite the parts of these two functions
that need case-insensitive matching in a way that doesn't need to bind
case-fold-search.  For example, case-insensitive match against "abcd"
using string-match can be replaced by a case-sensitive match against
"[aA][bB][cC][dD]" or by a call to compare-strings.

> AFAIU, it is very hard to rewrite them in C, as I explained in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66117#157

The only explanation I see there is that they "recursively call
other Elisp functions".  Is there any other reason?

My point is that by trying to speed-up let-binding of case-fold-search
and similar variables you are trying to solve a much more general
problem, and a much harder one at that.  IME, if an idea for a
solution leads to a more general and harder-to-solve problem than the
original, then the idea should be dropped, and one should look for
alternative ideas.

Previous Next

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