bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening large nu


From: Eli Zaretskii
Subject: 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@posteo.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, dmitry@gutov.dev,
>  66117@debbugs.gnu.org
> Date: Wed, 13 Dec 2023 13:06:06 +0000
> 
> Eli Zaretskii <eliz@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.





reply via email to

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