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: Tue, 12 Dec 2023 20:36:48 +0200

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: monnier@iro.umontreal.ca, dmitry@gutov.dev, 66117@debbugs.gnu.org
> Date: Tue, 12 Dec 2023 17:44:15 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >>   #define BVAR(buf, field) (buffer_overrides->field ## _ == UNSET ?\
> >>                               (buf)->field ## _ :\
> >>                              buffer_overrides->field ## _)
> >> 
> >>   and replace the loop with simply setting buffer_overrides slot.
> >
> > So for starters, we make each BVAR more expensive, i.e. make Emacs
> > uniformly slower (because we call BVAR all over the place).
> 
> Yes, although I do not believe that it will have large impact in
> practice. It is just an extra == comparison.

We've seen how similar extra comparisons slow down Emacs when we
introduced symbols-with-location.  IMO, BVAR might be even more
expensive, since it is used much more frequently and widely.

> > ... And then
> > I'm not sure I understand how buffer_overrides will get the values of
> > those temporary bindings without having to use the same loops when we
> > have let-binding within another one.  Also, what about threads?
> 
> Just as any other global state variable - via `specbind'. Entering inner
> let will push the previous value into specpdl and recover it upon
> exiting.

And that will not require looping similar to what we have now?

> Threads work similarly, maintaining their own local specpdl queue heads
> that make sure that global state is recorded and rewinded as needed.

I don't think I follow you here.





reply via email to

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