From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko 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:41:01 +0300 Message-ID: <87zg1ewfc2.fsf@localhost> References: <878r919qfh.fsf@localhost> <72c93fb0-bf3e-3dad-69c0-2147cfa40f57@gutov.dev> <875y42xyex.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30022"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66117@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 22 14:41:22 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 1qjfTE-0007bC-JQ for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Sep 2023 14:41:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjfSy-0003zC-HP; Fri, 22 Sep 2023 08:41:04 -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 1qjfSn-0003yd-5d for bug-gnu-emacs@gnu.org; Fri, 22 Sep 2023 08:40:54 -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 1qjfSl-0004NH-EU for bug-gnu-emacs@gnu.org; Fri, 22 Sep 2023 08:40:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qjfSv-0005DF-Vy for bug-gnu-emacs@gnu.org; Fri, 22 Sep 2023 08:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Sep 2023 12:41: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.169538640719963 (code B ref 66117); Fri, 22 Sep 2023 12:41:01 +0000 Original-Received: (at 66117) by debbugs.gnu.org; 22 Sep 2023 12:40:07 +0000 Original-Received: from localhost ([127.0.0.1]:35526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjfS2-0005Bv-G0 for submit@debbugs.gnu.org; Fri, 22 Sep 2023 08:40:06 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:55135) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjfRz-0005BI-HL for 66117@debbugs.gnu.org; Fri, 22 Sep 2023 08:40:04 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E121A240028 for <66117@debbugs.gnu.org>; Fri, 22 Sep 2023 14:39:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695386386; bh=SpLPxrqufFmSk4SeITA8VHRoWBL+olkHpCKwV0NEdOI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=AzCnrryMs4fy8djQkX1peVY88It+3MwtRFnhXW22aRadjFTXVFax/6123/tA+FUIV jkdlAoucCE9AimQNqTjHUXWnodDH0MoyhN8q6frpD0OFiN244fQrfl+vBH9exCcXoj E/sgY7BSpbTQ/QOeaKwbxRB8EPiH+eyF0WJmbGgD0fjErhfp1aeflT0K+0w3diT92v zod1n079Dj7W2yzXRAtKI3G2qWe0LnxaeaffSb5OqTPqnBk+je0pYY5d7gqkJkL9nG 6Q3j4xvTkX25xYsYcz3dyQOXfyD8e++PtsaU0l994v9EZApak5Qs1mVcGQ/1shzLMO A4uk3SqisMSGg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RsX0K6x6gz6tw1; Fri, 22 Sep 2023 14:39:45 +0200 (CEST) In-Reply-To: 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:271085 Archived-At: Dmitry Gutov writes: >> 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. Not a no-go, but not a complete solution either. I asked the user who provided the profiler report I have attached to replace `find-buffer-visiting' with `get-file-buffer' in the relevant Org sources and it did lead to ~30% runtime reduction. However, upon recording the profiler report with that change, `find-buffer-visiting' still took a significant fraction of CPU time. So, I decided to reach out upstream. Will it be acceptable to implement the cache using variable watchers? >> 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). The regression might happen when the number of buffers is small - when hash tables become slower compared to simple list lookup. But in such scenario, we will be talking about very small absolute runtimes anyway, so it should probably not matter in practice. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at