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

Previous Next

Full log

View this message in rfc822 format

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: bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening large number of buffers
Date: Tue, 12 Dec 2023 21:20:06 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: monnier <at> iro.umontreal.ca, dmitry <at> gutov.dev, 66117 <at> debbugs.gnu.org
> Date: Tue, 12 Dec 2023 19:18:19 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > 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.
> 
> It might. Do you know a good way to test such thing? Because I do not
> think that a mere suspicion that this change might make things slower
> should stop the discussion.

To measure such things, you need to run some benchmarks.
Byte-compiling might be one such kind; "make bootstrap" could be
another; scrolling one line at a time through a large file could be
yet another one.  Several such benchmarks were posted to the lists on
several similar occasions.

Previous Next

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