unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Sergey Vinokurov <serg.foo@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 53242@debbugs.gnu.org
Subject: bug#53242: [PATCH] unify reads from local_var_alist
Date: Fri, 14 Jan 2022 21:01:46 +0000	[thread overview]
Message-ID: <1e4edf7d-7f9c-ef56-7870-6f0f3567a40d@gmail.com> (raw)
In-Reply-To: <83ilum16qq.fsf@gnu.org>

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.





  reply	other threads:[~2022-01-14 21:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14  0:23 bug#53242: [PATCH] unify reads from local_var_alist Sergey Vinokurov
2022-01-14  7:49 ` Lars Ingebrigtsen
2022-01-14  8:08 ` Eli Zaretskii
2022-01-14  8:33   ` Lars Ingebrigtsen
2022-01-14 18:37   ` Sergey Vinokurov
2022-01-14 19:01     ` Eli Zaretskii
2022-01-14 21:01       ` Sergey Vinokurov [this message]
2022-01-15  7:32         ` Eli Zaretskii
2022-01-15 11:41           ` Sergey Vinokurov
2022-01-15 16:02             ` Corwin Brust
2022-01-15 17:54               ` Sergey Vinokurov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1e4edf7d-7f9c-ef56-7870-6f0f3567a40d@gmail.com \
    --to=serg.foo@gmail.com \
    --cc=53242@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).