bug#53242: [PATCH] unify reads from local_var_alist

[Sergey Vinokurov]

On 14/01/2022 19:01, Eli Zaretskii wrote:
> > Date: Fri, 14 Jan 2022 18:37:45 +0000
> > Cc: 53242@debbugs.gnu.org
> > From: Sergey Vinokurov <serg.foo@gmail.com>
> >
> > > How long can local_var_alist be?  This change will not allow the user
> > > to C-g from a long search.  Do we care?  How about using Fassq
> > > consistently instead?
> >
> > This list is not directly observed by the user. The lookups happen
> > during reads and writes of the buffer-local variables so if it's really
> > slow the only effect user would observe is that elisp got slow. There's
> > no single point for the user to C-g from.
>
> ?? What do you mean?  Long operations in Emacs generally periodically
> check for user's quitting, andif they detect C-g, they throw to
> top-level.  assq_no_quit doesn't.
> > This list definitely cannot be longer than a list of all the global
> > variables ever defined. This upper bound is probably a high number, but
> > not astronomically high.
>
> The question I asked was: it high enough to cause annoyingly long
> operations in some cases, and whether we care that users will no
> longer be able to interrupt such long operations.  You seem to assume
> that the number cannot be high enough, but I see no basis for that
> assumption in what you wrote.

My reasoning is as follows: consider what is stored in the 
local_var_alist. It's only for buffer-local variables, no other entries 
should get into the list. Thus the size of this list is directly 
proportional to the number of local variables in current buffer.

How many local variable bindings could be defined at the same time? Any 
amount, really. There can be no local variables or, in pathological 
case, there can be any number of them (consider a program executing 
`(dolist (i N) (set (make-local-variable (intern (format "foo%s" i))) 
i))` with arbitrary N). I argue that something's wrong if there are so 
many local variables defined that lookups into the local_var_alist would 
cause significant delays.

The lookups will happen each time a buffer-local variable is read or 
written to in elisp. If these lookups take a long time then any elisp 
working with these variables become slow. My argument is that at this 
point we don't care whether user is able to interrupt basic operations 
of reading and writing buffer-local variables. Even if we use Fassq and 
the user could interrupt, nothing is gained in my opinion - any command 
that involves reading or writing buffer-local variables will still 
remain slow.