From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening large number of buffers Date: Sat, 23 Sep 2023 11:57:03 +0300 Message-ID: <83zg1d468w.fsf@gnu.org> References: <878r919qfh.fsf@localhost> <72c93fb0-bf3e-3dad-69c0-2147cfa40f57@gutov.dev> <875y42xyex.fsf@localhost> <87zg1ewfc2.fsf@localhost> <834jjm749q.fsf@gnu.org> <87cyyawd1a.fsf@localhost> <83pm2a5k85.fsf@gnu.org> <87wmwh2tae.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7965"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, 66117@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 23 10:58:04 2023 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 1qjySh-0001qK-Rd for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Sep 2023 10:58:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjySX-0002Jj-4X; Sat, 23 Sep 2023 04:57:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjySV-0002J1-Ah for bug-gnu-emacs@gnu.org; Sat, 23 Sep 2023 04:57:51 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qjySV-0001AQ-2a for bug-gnu-emacs@gnu.org; Sat, 23 Sep 2023 04:57:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qjySf-0001IE-PL for bug-gnu-emacs@gnu.org; Sat, 23 Sep 2023 04:58:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Sep 2023 08:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66117 X-GNU-PR-Package: emacs Original-Received: via spool by 66117-submit@debbugs.gnu.org id=B66117.16954594354906 (code B ref 66117); Sat, 23 Sep 2023 08:58:01 +0000 Original-Received: (at 66117) by debbugs.gnu.org; 23 Sep 2023 08:57:15 +0000 Original-Received: from localhost ([127.0.0.1]:37760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjyRu-0001H4-HM for submit@debbugs.gnu.org; Sat, 23 Sep 2023 04:57:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjyRq-0001Gi-3V for 66117@debbugs.gnu.org; Sat, 23 Sep 2023 04:57:13 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjyRY-0000t3-LF; Sat, 23 Sep 2023 04:56:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ZfHwvyO6IGiDvzUy3IKU9sqRNH7INqLYDYEgB17qH7k=; b=DJqg/4KZJ0sz Er8/NInX9SX2m3KtaKf/+drLcXUEV2j3aRvvJGG+WnycNXCMV7RFgevbSyvszvfUg7n6vhyFJG+q5 IBc73ntJSzD0XLQtnf9kPR54uli9Q6AliYTxwAxL7/SRQq+mGPkUyJ3uH92ODQmYwMHsYP4mfyw7s TC9fO7EWmSJ0/2JCgaE4VAsu8xJDOGH+l64RJQdmzD/vYhC7hkG3Z9W1Ps5DIAutws45FJBYAP7oM mgwQK4ERchuJudM0RGr4VuHaZeEW1SMV3UJs4FU2IzsPDxAxGtn2OVhT4w35qAtFLEShNkceRckl5 C6qqLbFXJ+XRux2DP9phmw==; In-Reply-To: <87wmwh2tae.fsf@localhost> (message from Ihor Radchenko on Sat, 23 Sep 2023 08:22:17 +0000) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:271147 Archived-At: > From: Ihor Radchenko > Cc: dmitry@gutov.dev, 66117@debbugs.gnu.org > Date: Sat, 23 Sep 2023 08:22:17 +0000 > > Eli Zaretskii writes: > > >> Because `buffer-file-name' can be modified from Lisp (via > >> `set-visited-file-name' or directly). Same for `buffer-file-truename' > >> and `buffer-file-number'. > > > > You could update the cache in set-visited-file-name, and ignore > > direct changes. > > I have eyeballed Emacs sources, and it looks like a huge number of > libraries sets `buffer-file-name' directly. I think this is an exaggeration, see below. > Also, even `find-file-noselect' does not use > `set-visited-file-name'. Why does it matter? We need to catch this in find-file-noselect and in set-visited-file-name anyway. > - Functions setting ~buffer-file-name~ manually (except those setting it to nil): > - tests > - ~vc-find-revision-no-save~ > - ~url-insert-buffer-contents~ > - ~plstore-open~ > - ~protect-innocence-hook~ (really?) > - ~tramp-handle-insert-file-contents~ > - ~tramp-archive-handle-insert-file-contents~ > - ~mailcap-view-file~ > - ~ange-ftp-parse-netrc~ > - ~ange-ftp-write-region~ > - ~ange-ftp-insert-file-contents~ > - ~mh-display-msg~ > - ~mh-make-folder~ > - ~mh-read-draft~ > - ~feedmail-vm-mail-mode~ > - ~feedmail-send-it~ > - ~jka-compr-write-region~ > - ~jka-compr-insert-file-contents~ > - ~image-dired-write-tags~ > - ~image-dired-remove-tag~ > - ~image-dired-write-comments~ > - ~hfy-buffer~ > - ~nndraft-request-associate-buffer~ > - ~nndraft-auto-save-file-name~ > - ~nnbabyl-create-mbox~ > - ~mm-display-inline-fontify~ > - ~mm-url-insert-file-contents~ > - ~mm-extern-url~ > - ~message-send-mail-with-mh~ > - ~message-set-auto-save-file-name~ > - ~gnus-dribble-read-file~ > - ~gnus-save-newsrc-file~ > - ~gnus-gnus-to-newsrc-format~ > - ~gnus-mime-copy-part~ IMO, these are not important for your purpose. The few buffers whose buffer-file-name is set as in those functions are not going to get in the way of your looking for a buffer that visits a specific name. And if a few of them do, we can always add the cache-updating code to them. > - ~find-alternate-file~ > - ~find-file-noselect-1~ (but not by default?) > - ~set-visited-file-name~ > - ~file-name-non-special~ These _must_ update the cache. > - ~erc-dcc-find-file~ > - ~epa-file-insert-file-contents~ > - ~epa-file-write-region~ > - ~save-completions-to-file~ > - ~load-completions-from-file~ > - ~archive-extract~ These belong to the first group, I think. > - Functions setting ~buffer-file-truename~ manually (except those setting it to nil): Are the cases where we find the buffer via file's truename significant in the profiles you've seen? if not, these functions are not relevant to the issue at hand. If the search by truename _is_ significant, we could cache that as well. > - ~tar-extract~ > - ~find-alternate-file~ > - ~find-file-noselect-1~ > - ~set-visited-file-name~ > - ~revert-buffer--default~ > - ~archive-extract~ > > > - Functions setting ~buffer-file-number~ manually (except those setting it to nil): Same question as for truename above. > - ~find-alternate-file~ > - ~find-file-noselect-1~ > - ~set-visited-file-name~ > - ~basic-save-buffer~ > > > >> Or should we just assume that these variables remain unchanged other > >> than by primitives? > > > > Programs that make these changes are asking for trouble, IMO. AFAICT, > > find-buffer-visiting will never find such buffers anyway. > > It would, in its current form. Because it calls `get-file-buffer' that > loops over all the buffers and checks their buffer-local > `buffer-file-name' value, including values set via `setq' in Elisp. Again, which of the loops took the significant time in the profiles you have? the one in get-file-buffer or the ones in find-buffer-visiting?