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, 07 Oct 2023 11:48:21 +0300 Message-ID: <838r8e24yy.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> <83zg1d468w.fsf@gnu.org> <87bkdr2651.fsf@localhost> <87pm2584oz.fsf@localhost> <83cyy11ln1.fsf@gnu.org> <87lecp84mf.fsf@localhost> <83ttrdx8j9.fsf@gnu.org> <87a5su261p.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1736"; 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 Oct 07 10:48:58 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 1qp2zY-0000Bt-Mp for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 07 Oct 2023 10:48:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qp2zM-0002Wt-SZ; Sat, 07 Oct 2023 04:48:44 -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 1qp2zL-0002Wb-Hw for bug-gnu-emacs@gnu.org; Sat, 07 Oct 2023 04:48:43 -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 1qp2zL-0000xI-9o for bug-gnu-emacs@gnu.org; Sat, 07 Oct 2023 04:48:43 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qp2ze-0006Nv-Is for bug-gnu-emacs@gnu.org; Sat, 07 Oct 2023 04:49:02 -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, 07 Oct 2023 08:49: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.169666851624375 (code B ref 66117); Sat, 07 Oct 2023 08:49:02 +0000 Original-Received: (at 66117) by debbugs.gnu.org; 7 Oct 2023 08:48:36 +0000 Original-Received: from localhost ([127.0.0.1]:53296 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qp2zD-0006L0-QM for submit@debbugs.gnu.org; Sat, 07 Oct 2023 04:48:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qp2zB-0006KC-Gn for 66117@debbugs.gnu.org; Sat, 07 Oct 2023 04:48:34 -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 1qp2ym-0000hu-NY; Sat, 07 Oct 2023 04:48:08 -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=7f99UIdvOs6BuOuGLTcjZNqGxmIGbE2IMGMEOlgCCts=; b=qMdRClvuLcF4 MAMuIXFyLZvcL4izE3iF/KJ+pKcFqSNl1o+Kq74qjgXMKDWKTOKh+QRi8rSi4MighIGmk+ZI8vXiG M5OLxI6MSSxcIFet3z1MPjftJr7lxtnSP9IakCF89C++0Jz/Ddg4jqsTbo5fLHEk/V+Y0ju5M9K1A 2JsK6RjgMFqRSkTdOvVcwoQgaXWlmjnK2DzylstI9Z1oKnjT36/o2NvX0ImttRO2el5Ea1mi6Rear WYmXn37GtwiSaV7lRUS2x4HMUVbdMRyPTLIVpKN5fRKcpH5lGpVJbi+vo1XGm4qy/hYfN5nfGlWgs mmqPsJotx3Fl1EMc6wbi9Q==; In-Reply-To: <87a5su261p.fsf@localhost> (message from Ihor Radchenko on Sat, 07 Oct 2023 08:25:06 +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:271983 Archived-At: > From: Ihor Radchenko > Cc: dmitry@gutov.dev, 66117@debbugs.gnu.org > Date: Sat, 07 Oct 2023 08:25:06 +0000 > > Eli Zaretskii writes: > > >> >> If one uses `get-file-buffer' instead of `find-buffer-visiting', the > >> >> total runtime becomes 5.1 sec - almost 4x faster. > >> > > >> > This is also not very interesting, since find-file-noselect calls > >> > get-file-buffer as well. > >> > >> No. `find-file-noselect' calls `find-buffer-visiting'. > > > > Unless we use different Emacsen, find-file-noselect calls both > > get-file-buffer and find-buffer-visiting: > > > > (let* ((buf (get-file-buffer filename)) <<<<<<<<<<<<<<<<<<<<<<<<<<<< > > We are probably mis-communicating. My point is that `get-file-buffer' is > very fast (for my purposes). So, it does not matter as much if it is > called somewhere else and how many times. It matters to me. Timing code must be very accurate and must not modify the code in question, certainly not by invoking the same primitives that are already called by the code being times. I must say that this discussion is very frustrating from my POV. Lots of information, a large portion of it irrelevant, and very little systematical analysis of the involved code, its actual performance, and the conclusions with numbers to back them up. On top of that, gaps for a week or more between a message and a response, something that makes it hard to follows the discussion. We should be able to do better. > >> I still think that my previous conclusions are true. And I agree that > >> rewriting these expensive loops in C makes sense. Maybe two new > >> subroutines to find buffer by `buffer-file-truename' and by > >> `buffer-file-number'? > > > > Yes, that's what I had in mind. > > I looked closer, and there is already `get_truename_buffer', which can > simply be exposed to Lisp. > > `buffer-file-number' is a bit more tricky - it is not defined in C, but > in files.el. However, I am wondering if this variable should be moved to > C or maybe into the buffer object. `make-indirect-buffer' (defined in C) > has > > Fset (intern ("buffer-save-without-query"), Qnil); > Fset (intern ("buffer-file-number"), Qnil); > > WDYT? TTTT, I don't know what to think. >From my POV, there are two alternatives here: . expose several new primitives to Lisp to make find-buffer-visiting faster without changing the way we store the file-to-buffer association information . introduce caches or change the way file-to-buffer associations are stored to speed up find-buffer-visiting What I'd like to see is that someone implements the first idea, and times find-buffer-visiting after that to see if it becomes fast enough. Then we can discuss whether anything else is needed. > >> Aside: this reminds me about obsoletion of generalized buffer-local > >> variable. AFAIU, there is currently no way to set buffer-local value in > >> buffer without setting that buffer to current. It would be nice if such > >> setting were possible, especially in performance-critical code. > > > > Maybe, but is there any performance-critical code which needs that? > > For example, org-element.el needs to set buffer-local values in base > buffer of an indirect buffer every time buffer text is being edited. And that is performance-critical? in what way and in which situations?