From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#66117: 30.0.50; `find-buffer-visiting' is slow when opening large number of buffers Date: Fri, 22 Sep 2023 15:11:26 +0300 Message-ID: References: <878r919qfh.fsf@localhost> <72c93fb0-bf3e-3dad-69c0-2147cfa40f57@gutov.dev> <875y42xyex.fsf@localhost> 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="37828"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: 66117@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 22 14:12:12 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 1qjf12-0009d8-92 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Sep 2023 14:12:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjf0k-0002Xp-DB; Fri, 22 Sep 2023 08:11:54 -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 1qjf0i-0002Xd-I3 for bug-gnu-emacs@gnu.org; Fri, 22 Sep 2023 08:11:52 -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 1qjf0i-0005kD-02 for bug-gnu-emacs@gnu.org; Fri, 22 Sep 2023 08:11:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qjf0s-0001pJ-HD for bug-gnu-emacs@gnu.org; Fri, 22 Sep 2023 08:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Sep 2023 12:12:02 +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.16953847087001 (code B ref 66117); Fri, 22 Sep 2023 12:12:02 +0000 Original-Received: (at 66117) by debbugs.gnu.org; 22 Sep 2023 12:11:48 +0000 Original-Received: from localhost ([127.0.0.1]:35486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjf0e-0001or-Bw for submit@debbugs.gnu.org; Fri, 22 Sep 2023 08:11:48 -0400 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]:38543) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjf0c-0001od-6q for 66117@debbugs.gnu.org; Fri, 22 Sep 2023 08:11:47 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 16A7C5C016D; Fri, 22 Sep 2023 08:11:30 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 22 Sep 2023 08:11:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1695384690; x=1695471090; bh=PxzrH6EJaS51wDWrIMOjHPqzOpVeNjBJFni YNIUfnMs=; b=ixS77j+KoCuNyvJOLpn/cpSRScDcIj4/G8LzyNnKO3WiiXROb3w kt4sR1gwR1lwSbNOGAJlY2s+vT1bIADBBCVj5VkAUCCPsa2wtPSMgTQHZruw/iAc aE1E3dEnNL6xT4E+pjbdXkvDpGBB7XUBYiwEyK3ly7kv/jX4XEf2nHZNKPjvtqkj Yviy1jpNBT9l4jYw1Z30L/A9V2NycF5+CyQ1cvm2xYvjXuLQcWpDnWMjh0Pi6nPi HAkvqkFDWdDDNl1WO3IpnVs1ULg//8KWAnleD4k00Yrnhlvjl9PYKCqVk2pyKD9q 2i9sdysb8A3ST5xObB9gsosPZ4Yi28o+ATQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695384690; x=1695471090; bh=PxzrH6EJaS51wDWrIMOjHPqzOpVeNjBJFni YNIUfnMs=; b=otuuoZ9sDZ7hKB5S9fZNhJ8mpegtkZViYq6kChCpQ6DXHKGPbrJ jmOfB8tu7vQlKimZVd0WsW4z+F3RblcU9YKJvYzZzGRndJKmBlkixJhl/EH9WpZO i/hwfPdDfdmEKwF/zPPn8ozGkj+yYOGKu22Sb4yUqpt4I3LPfqg7KJGcQmueQ6F0 TuQ0+/57KducNAmHZVPruWH7L5sy9qSTnkP/SWtzYG9Nh6+f14PsXAod8h/tZySJ 23hdwkAsLceWjUNil+l9Ox0FyqM/sja5Sfb14YiEf/z4pUSeTK/jIVn2MT/QyOU4 07JTWVC7BGvJ73U5GAEOS8tuUYAuXh6OyUA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekkedgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfevfhfhjggtgfesth ejredttdefjeenucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehg uhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpeeigfetveehveevffehledtueekie eikeeufeegudfgfeeghfdulefgfeevledvveenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 Sep 2023 08:11:28 -0400 (EDT) Content-Language: en-US In-Reply-To: <875y42xyex.fsf@localhost> 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:271079 Archived-At: On 22/09/2023 14:03, Ihor Radchenko wrote: > Dmitry Gutov writes: > >>> Would it be possible to implement some kind of caching mechanism to be >>> used by `find-buffer-visiting'? >> >> I'm guessing you Cc'd me because of an existing comment inside xref.el? > > Actually, mostly because I though that this discussion might be of > interest for you. All right, thank you for that. >> As you can see I decided not to use this function there, but even >> get-file-buffer wasn't as fast as I would've wanted, so there's a >> quick-and-dirty caching solution for sequential lookups (which assumes >> that the same file would be looked up multiple times in a row). > > For me, the situation is different - a new not-yet-open file is looked > up multiple times in a row, which is a bit more tricky. This could be handled with a locally held dictionary as well, but... >> Putting aside the perspective of maintaining a cache in the core >> (hopefully this will be discussed later in this feature request), any >> chance you could initialize that cache yourself first (by iterating >> through buffers and building file-truename -> buffer map), before you >> are doing those many lookups? Somewhere in org-agenda-list, perhaps. >> >> That should change the complexity from N*M to N+M, more or less. > > Sure. That's my plan to address older Emacs versions. But such iteration > will involve copy-pasting a big part of `find-buffer-visiting' source > code, which is not something I want to maintain in a long term (what if > `find-buffer-visiting' changes in future?). > > Moreover, `find-buffer-visiting' is called by `find-file-noselect', and > I simply cannot make use of cache there without modifying the code > upstream; or writing my own version of `find-file-noselect' - bad idea > maintenance-wise. ...if most of said calls are done through find-file-noselect, I suppose that solution is a no-go. > I think that the best way that will benefit more than Org mode is > arranging internal cache that will link buffer-file-name, > buffer-file-truename, and buffer-file-number with buffers; and maintain > the correctness of the cache if buffer-file-name changes for any reason. I think that is doable. It probably won't regress the performance of any particular scenario either, but we should benchmark opening a bunch of files this way anyway (might actually get faster, due to find-buffer-visiting calls).