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: Sun, 24 Sep 2023 15:50:38 +0300 Message-ID: <83pm273fc1.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14867"; 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 Sun Sep 24 14:52:28 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 1qkOb5-0003ei-1B for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 Sep 2023 14:52:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qkOab-0006Zq-VT; Sun, 24 Sep 2023 08:51:59 -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 1qkOaU-0006XH-OR for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2023 08:51:50 -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 1qkOaU-0003V5-GF for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2023 08:51:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qkOaf-0003Bc-VR for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2023 08:52: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: Sun, 24 Sep 2023 12:52: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.169555991412165 (code B ref 66117); Sun, 24 Sep 2023 12:52:01 +0000 Original-Received: (at 66117) by debbugs.gnu.org; 24 Sep 2023 12:51:54 +0000 Original-Received: from localhost ([127.0.0.1]:41294 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkOaX-0003A2-MY for submit@debbugs.gnu.org; Sun, 24 Sep 2023 08:51:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkOa8-00037U-EY for 66117@debbugs.gnu.org; Sun, 24 Sep 2023 08:51:29 -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 1qkOZp-0003L6-UJ; Sun, 24 Sep 2023 08:51:09 -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=5QX4hpMR2DXPlNwHY6+rE5RuQwSmWzTApu3J8MXMF1I=; b=b4s0Lgvijsvn Gb95qD5fUDSLqwbBYplDO7ETzoZFxxm6+CtWhZpKoRia5hzjAHrP6P8pZKPHhzkCL/KAykGjDJT1I jgIGICtUloT43zqj5fFQVv0Q/9TdG5QoBzv+FU1dHwvYEHMFS8+IdCb6kzuQb0VnhE10NMyqcWq1C XbCm4AmZ5IvnMBRZyidoX5U5UAIam5G15MZmyrVlrOFT/cuLc13oWCLWmOmfSe46s5uXcXy2r03Q2 JcDwfrQNiLgd9wZaGsJbb7DJkXs7Apbiej1GonriFGYxhz/jEejmI1YnBXBKCi6TKK/QAStI25nJq o6QrAYJrbidBf0+Jn5iTwg==; In-Reply-To: <87bkdr2651.fsf@localhost> (message from Ihor Radchenko on Sun, 24 Sep 2023 10:54:34 +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:271243 Archived-At: > From: Ihor Radchenko > Cc: dmitry@gutov.dev, 66117@debbugs.gnu.org > Date: Sun, 24 Sep 2023 10:54:34 +0000 > > Eli Zaretskii writes: > > >> 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. > > Mostly because I feel that I misunderstand where `buffer-file-name' is > set. `find-file-noselect-1' only sets `buffer-file-name' when > > (if find-file-visit-truename ;; defcustom, nil by default > (setq buffer-file-name (expand-file-name buffer-file-truename))) > > >> - ~find-alternate-file~ > >> - ~find-file-noselect-1~ (but not by default?) > >> - ~set-visited-file-name~ > >> - ~file-name-non-special~ > > > > These _must_ update the cache. > > I feel that I am still missing where `buffer-file-name' is set when > opening file via C-x C-f. Debugger showed something weird in my testing. With local files, it seems like insert-file-contents sets it. So maybe we should record the file name in the cache in bset_filename. > >> - 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? > > Not significant for the profiles I got, but I did not want to break the > existing code. > > > ... 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. > > Just to make sure that we are on the same page: the cache I am proposing > should be complete - if a buffer is missing from the cache, we should be > sure that there is no matching buffer. Since we will keep buffer-list (we must), even with this cache available, we can always leave the current code that scans the buffer list if the name is not in the cache. This way, we don't need to worry to have all the buffers in the cache, only those which are looked for frequently and need the efficiency. > `find-buffer-visiting' explicitly checks for `buffer-file-truename'. > So, if the cache does not account for `buffer-file-truename', there will > be divergence between the existing code and when using the cache. > > Same argument for `buffer-file-number' As I said, we could have hash-tables for these as well, if that is needed. But I'd like to see the profiles that indicate we do need them. > >> > 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? > > Most of the time was taken by `find-buffer-visiting'. Replacing > `find-buffer-visiting' with `get-file-buffer' in certain (not all) > places reduced the total runtime by 30%. So you are saying that 30% of file-visiting buffers are not found by get-file-buffer? Or is the 30% increase due to file names for which there's no corresponding buffer? If so, does the benchmark indeed look for so many buffers that don't exist? > I will try to setup a test on my machine for more detailed data. Thanks, I think we need to understand the hot spots better, indeed.