From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Ihor Radchenko <yantar92@posteo.net>
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>
 <ad093541-b473-6a7f-7012-b4d6f7242586@gutov.dev>
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 <dmitry@gutov.dev>
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: <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org>
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 <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org>)
	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 <bug-gnu-emacs-bounces@gnu.org>)
	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 <Debian-debbugs@debbugs.gnu.org>)
 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 <Debian-debbugs@debbugs.gnu.org>)
 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 <Debian-debbugs@debbugs.gnu.org>) 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 <yantar92@posteo.net>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Fri, 22 Sep 2023 12:41:01 +0000
Resent-Message-ID: <handler.66117.B66117.169538640719963@debbugs.gnu.org>
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 <debbugs-submit-bounces@debbugs.gnu.org>)
 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 <yantar92@posteo.net>) 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: <ad093541-b473-6a7f-7012-b4d6f7242586@gutov.dev>
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" <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-gnu-emacs>,
 <mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-gnu-emacs>
List-Post: <mailto:bug-gnu-emacs@gnu.org>
List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>,
 <mailto:bug-gnu-emacs-request@gnu.org?subject=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: <http://permalink.gmane.org/gmane.emacs.bugs/271085>

Dmitry Gutov <dmitry@gutov.dev> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>