Re: ido-switch-buffer is slow with many buffers; others are fast

[Spencer Baugh]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> The associated bug#41029 mentions:
>>> Many of the buffer locals (in particular I think it's the
>>> SYMBOL_FORWARDED types --- my terminoly may be off), appear to be O(n)
>>> to bind, where n is the number of live buffers.
>> That's quite worrying - that implies that pretty much any code will run
>> slower as the number of buffers increases, even if it doesn't have
>> anything to do with buffers!
>
> Yup.
> It affects all the vars defined via `DEFVAR_PER_BUFFER`.
>
>> This explains the slow performance of let-binding case-fold-search
>> that I mentioned in another branch of this thread.
>
> Yes it's the source of that problem.
>
>> Is this poor scaling of binding buffer locals a known problem?
>
> At least since bug#41029, yes ;-)
>
>> Has anyone worked on fixing this?
>
> Not that I know, no.
>
> It's a fairly tricky part of the code, but if you're interested, I'd be
> very happy to help you along (I'm familiar with this code for having
> reworked it somewhat around the time of Emacs-24).

I'm not sure I have the requisite expertise, but I have the motivation,
so yes, I'll give fixing this a try.

If I'm guessing right, the problem is the NILP (Flocal_variable_p
(symbol, Qnil)) case of specbind, on line 3351 of eval.c. In that case,
the let-binding actually changes the "global" value of the variable.

So in turn, we call do_specbind, which calls set_default_internal, which
iterates over all buffers to set the buffer slot to the "global"
value. And then I guess we again reset the value in all live buffers
when unwinding the let?

(Actually, couldn't this be buggy if a new live buffer is created while
in the scope of the let? The new live buffer wouldn't have the value set
by the let-binding...)

It seems like maybe this could be fixed by having a true global value
for DEFVAR_PER_BUFFER which is checked on variable read when there's no
buffer-local binding. Then a let-binding which changes the "global"
value would just, change that value. I'm not sure why it doesn't already
work like that?

I added arnold@tdrhq.com to CC since they filed bug#41029 in the first
place. Arnold - you mentioned trying to optimize the binding process in
the bug. Do you have any more detail about what you tried that didn't
work out?