From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sergey Vinokurov Newsgroups: gmane.emacs.bugs Subject: bug#53242: [PATCH] unify reads from local_var_alist Date: Fri, 14 Jan 2022 21:01:46 +0000 Message-ID: <1e4edf7d-7f9c-ef56-7870-6f0f3567a40d@gmail.com> References: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> <83zgny20z2.fsf@gnu.org> <74db84b1-5433-dfb8-8ee3-9d86d8fc9be7@gmail.com> <83ilum16qq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18380"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Cc: 53242@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 14 22:02:13 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n8Ti8-0004aj-2Y for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jan 2022 22:02:12 +0100 Original-Received: from localhost ([::1]:38110 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n8Ti6-0006yf-Mb for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jan 2022 16:02:10 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52464) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8Thy-0006vP-6I for bug-gnu-emacs@gnu.org; Fri, 14 Jan 2022 16:02:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45449) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n8Thx-0008WP-RN for bug-gnu-emacs@gnu.org; Fri, 14 Jan 2022 16:02:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n8Thx-0005Jc-LD for bug-gnu-emacs@gnu.org; Fri, 14 Jan 2022 16:02:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Sergey Vinokurov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jan 2022 21:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53242 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 53242-submit@debbugs.gnu.org id=B53242.164219411620421 (code B ref 53242); Fri, 14 Jan 2022 21:02:01 +0000 Original-Received: (at 53242) by debbugs.gnu.org; 14 Jan 2022 21:01:56 +0000 Original-Received: from localhost ([127.0.0.1]:38352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8Ths-0005JJ-6Z for submit@debbugs.gnu.org; Fri, 14 Jan 2022 16:01:56 -0500 Original-Received: from mail-wm1-f43.google.com ([209.85.128.43]:38731) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8Thp-0005Iy-0T for 53242@debbugs.gnu.org; Fri, 14 Jan 2022 16:01:54 -0500 Original-Received: by mail-wm1-f43.google.com with SMTP id p1-20020a1c7401000000b00345c2d068bdso9383104wmc.3 for <53242@debbugs.gnu.org>; Fri, 14 Jan 2022 13:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=OIvrhf6IE1/wOjyf7baP7UK6yF6tso+yJGosVcHi+pg=; b=TaxnTY6hgrUPnbJOXxv+kW/pYVmmQ6GB0nEz+QvZBxU+KH5hg9w/YE+aQFuLKZrZGN 4QhfbiHKLGDxo+vGGlhxoXAK9QKngZjnNUjoSTk2+EDMGiFrdLCZ7P/XAn4XwpUD9BWF Kj8ZTuCsYJHBcg1xq8LQKGa8730JlppIgl88GroD9aKhSOc3sqpxppwZdnVlFixFXdKQ J46chJfE0V6BP9v1kuwpR8HBBEHN6fsLkTVo/33+bk+UTySazgRv2K9Ljf5iDfCToDka RyU3JLmQvbtHJxiiWB7w3/t8SGGJ4xkg08tPji78klDyKU1rQM+57ahF9yQzv/qyQdTe foxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=OIvrhf6IE1/wOjyf7baP7UK6yF6tso+yJGosVcHi+pg=; b=MR+p8XKfhCLdQCneZDEbQH3RApoibjP4HDgSrkP+bzjjjn3yomsSGxGsJojqi7S3Y2 MfhFT3S2gv4gPpjrAmOF5XnRXZjECvyBAvTuMaoxM/T326muVlDi7jcGD30GTMe/pJoH 7BMmpwHiMlTI84OmCz9pSxSbsgFf80yfFtFd53wSjwbu5/BTf8RWgSm3LX8P3flugb6m vSOnWFWnntsjaTqlKWSbKANNRnYV4x6KfeZpVsnDEoq5mEfVmRmqxxi7GwMNTSdYW1Sl pAxZDaLYubNgyD6MTn6PyDsyoqjo23/YVw7g2GsXC36nawfp4nafrPJUkakvhz9bA5F6 2WWg== X-Gm-Message-State: AOAM533f7CVCpeuFWmDhaNWXHv3pBUmUtbTEX4EyNpp3G3ilbAbXexEl 2vrWXPDodKoQdkB6w9ZhtqgsU/ehU34= X-Google-Smtp-Source: ABdhPJxvKh8x8KerEyMFNXQgP1bo+nmCrxCCNnK3V4Ef0e9RrG2tR24SM6tRDgNpIiaM5Sd86PdIfg== X-Received: by 2002:a5d:69ce:: with SMTP id s14mr8506836wrw.427.1642194107277; Fri, 14 Jan 2022 13:01:47 -0800 (PST) Original-Received: from ?IPV6:2a01:4b00:8697:de00:607c:1dff:fe2e:2452? ([2a01:4b00:8697:de00:607c:1dff:fe2e:2452]) by smtp.gmail.com with ESMTPSA id o11sm12173564wmq.15.2022.01.14.13.01.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Jan 2022 13:01:46 -0800 (PST) Content-Language: en-GB In-Reply-To: <83ilum16qq.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:224235 Archived-At: 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 >> >>> 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.