From unknown Wed Jun 18 00:17:29 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#78545 <78545@debbugs.gnu.org> To: bug#78545 <78545@debbugs.gnu.org> Subject: Status: 31.0.50; project-mode-line is slow because it tries to read files on each update Reply-To: bug#78545 <78545@debbugs.gnu.org> Date: Wed, 18 Jun 2025 07:17:29 +0000 retitle 78545 31.0.50; project-mode-line is slow because it tries to read f= iles on each update reassign 78545 emacs submitter 78545 Yikai Zhao severity 78545 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Thu May 22 02:16:48 2025 Received: (at submit) by debbugs.gnu.org; 22 May 2025 06:16:49 +0000 Received: from localhost ([127.0.0.1]:58789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uHzET-0004Oh-Jj for submit@debbugs.gnu.org; Thu, 22 May 2025 02:16:48 -0400 Received: from lists.gnu.org ([2001:470:142::17]:34190) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uHzEL-0004Ju-N6 for submit@debbugs.gnu.org; Thu, 22 May 2025 02:16:40 -0400 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 1uHzDt-0007xj-Ra for bug-gnu-emacs@gnu.org; Thu, 22 May 2025 02:16:16 -0400 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uHzDo-0007Dm-KM for bug-gnu-emacs@gnu.org; Thu, 22 May 2025 02:16:08 -0400 Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3a375e72473so2392598f8f.0 for ; Wed, 21 May 2025 23:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=z1k.dev; s=google; t=1747894560; x=1748499360; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IEQuxaCiFOdDfvuONh0IWGxIIhT8bre1CgWYiMoO7KY=; b=bUVOYAqC2LgY6eltPaPyfLMybRy7Zl0q5865/w8IzRNhaUofQZUXKCO++Dk6/wylT6 eVSDOkgNQ9J8nXjR+GZ+Mo7q4js+zUFBVCzltmdfPckXC+ef48VOT4qYlaYwkOTlO6mA t42qXaZ5CXEyzESeH8SuFSX9tbcez4HMbMc5J8FolvJ/dMDgi62OqbeLCdNTlOs1ZBMv mOYHUytT6jsGd1J/L1GL9xoW6UMehS7fw2r8Q0qD76m3IHgqT1FuZj1q0vbxga8DT0y0 oOxYb3JtqhPHL458nlxRXs3kBokonj83rqccOYvUBV26jdPYfG5iVGs1oH2ZKVOJGaPd Lvaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747894560; x=1748499360; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IEQuxaCiFOdDfvuONh0IWGxIIhT8bre1CgWYiMoO7KY=; b=oHjfHBJnxyOf63CVFPvY5gnmJsBq36HDWmW/yGtq2mQqWTyGVLOOWlJMeoRWJa8bfy UkuiGN9TckmEIorKWKP2X5j+jcZox9nyx7CJRXvgb3+H85R9SyDSvRVwTfwTTg7tmRU+ Cr9tyZBoeB/JB8/qIQg9xXOXMIRvkxHbVuJxjKODt/himWoUhm0WY9maKOuxfOLiB3QY FKd5vbjMIDWCcOHnTFIUnu5vIvgLIxoNjCOgDEx6nVvR3mBjAGTsi6A1uHANdp84qf2H BuwsdT863CQFhBwrvzkGRB3hs/SBW6JjVPjuIFVAAmOmrNs38feaoxtY2agUF9kQmXo5 k5vw== X-Gm-Message-State: AOJu0YyvEEvTTGfhLDnagV3GhnpR36XHV6cYhO7FmtPL0A/v3uDkOfRR lDWDueecYW6HU19Srsmo6UQmlS5KUYxsqR+HjWmehkwmQwCo7gldYhohvU2IRyvLlEEbECTDosy FkNQxPd3el+/jhb/zwNFrfKu9xKmY7vjILb57GL/tNSHQLHUrkr8ViKI= X-Gm-Gg: ASbGncu+HU18GC4smFrwa7llND/QI2fPOMPb98ay8Fl3/TNEUtnl+XzxVEvHlV9KeIm fRzfKCAScZi+7GYQ/O+Z07Nz5fRSsBd5bo3YL2eCzwWtBpU+tPFcE7FA/TA0dxFkMLormpX5Hdm /SiBCNaMa81JpBxXS+psv9xdSog3AIhto/fQQ0iAG+AFFYRpyZQM3ITB6iLB/yq+MGgzc= X-Google-Smtp-Source: AGHT+IFZCcIbAXOfE2l+vgHJveqllTkGWsCfWnp8nfK360mGFiJnJoxoH13KZwwnqNWMXPrkzy6t69RaCnwiWTzyyy8= X-Received: by 2002:a05:6000:178c:b0:3a3:671e:3b7c with SMTP id ffacd0b85a97d-3a3671e3c09mr17680841f8f.48.1747894560341; Wed, 21 May 2025 23:16:00 -0700 (PDT) MIME-Version: 1.0 From: Yikai Zhao Date: Thu, 22 May 2025 14:15:49 +0800 X-Gm-Features: AX0GCFtIgHrdANH6PTknNMy9sWnJV8l93NQRQ0x11eMwfkLZnMJYLJyVTZGbuCY Message-ID: Subject: 31.0.50; project-mode-line is slow because it tries to read files on each update To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=i@blahgeek.com; helo=mail-wr1-x42a.google.com X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) After enabling `project-mode-line`, I find my emacs slightly less responsive. I think it's because project-mode-line is slow due to it trying to read files on each update. Here's how I reproduce it: - Run `emacs -Q` - Evaluate `(setopt project-mode-line t)` - Open some random file in a non-project directory, e.g. `/tmp/test`, start typing Here's part of the profiling result: 114 62% - redisplay_internal (C function) 42 23% - eval 41 22% - project-mode-line-format 41 22% - project-current 41 22% - project--find-in-directory 41 22% - run-hook-with-args-until-success 41 22% - project-try-vc 41 22% - project-try-vc--search 25 13% - project--value-in-dir 22 12% - hack-dir-local-variables 22 12% - # 22 12% - hack-dir-local--get-variables 22 12% - dir-locals-find-file 22 12% - locate-dominating-file 12 6% + abbreviate-file-name 3 1% + # 13 7% - locate-dominating-file 6 3% + # 3 1% abbreviate-file-name 3 1% It shows that `project-mode-line-format` can take a significant portion of the redisplay time. It increases even more when the directory is deep or the disk is slow. IMO the performance of this function should be improved. I have two questions: 1. Is it possible to simply cache the result as buffer-local? 2. IIUC some of the file reading comes from `project--value-in-dir`, which opens a temporary buffer to load dir local variables. Why doesn't it simply read the variable value in the current buffer? Thanks Yikai From debbugs-submit-bounces@debbugs.gnu.org Thu May 22 07:47:42 2025 Received: (at 78545) by debbugs.gnu.org; 22 May 2025 11:47:43 +0000 Received: from localhost ([127.0.0.1]:32944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uI4Ok-0007PO-9p for submit@debbugs.gnu.org; Thu, 22 May 2025 07:47:42 -0400 Received: from mail-vk1-xa32.google.com ([2607:f8b0:4864:20::a32]:60620) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uI4Oe-0007P2-0V for 78545@debbugs.gnu.org; Thu, 22 May 2025 07:47:37 -0400 Received: by mail-vk1-xa32.google.com with SMTP id 71dfb90a1353d-5259331b31eso2713839e0c.0 for <78545@debbugs.gnu.org>; Thu, 22 May 2025 04:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747914450; x=1748519250; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HW2wIaWpZf9icMxc3Mum9J/w49xc1ykSlJ8e57nCKvA=; b=a9Lg2NAcZlIMZCpl1jEH4dN06mvFYva+ZGZQFz8NRsX4I56Ymhwc7hCx17i2IX4ITQ LwskUHhGRviU96qeZ0hxM+y6sY6ePAV/3gzW0InpubYFDKV49QhEa265y0MMdz6JR18x Lyrk4j9i5OSO4d3DtoYinwp+AE8C76BPQvI9+N16hATTtccruRDracak6F6ctzRtD6Rt 9jZJzE9jW6QW6FvlICLhau/p3r5eFoGyeDDnHyduEm+UzZTyO1obYRU86NiFSwOWUCEH htaInIIbAEvSaAuGFAsgr4Q+Ry5f4Y+VnFY7xrON6dfseg2YbEWqQ/1DXSy1IQOB8HdU lvIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747914450; x=1748519250; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HW2wIaWpZf9icMxc3Mum9J/w49xc1ykSlJ8e57nCKvA=; b=vF4moCxKPgQr5uOOweiiF3IW9ny9pF82Bhml126/HuhewMi3bh1R1GQZE2GkvwUD11 utR7FLYE68rBRpQiXC5yEFSLc4HQXGDXe7CWG/WDF7afSCgWlWAungtNWNF+xzWYfr02 35Fr7opizTIzrO6k1q94FsoYdYBo1hLvEwc/SszFNSnSPQPQJgJreGbWQV9L7etPP+oq 06jP/9jwKMsw12T8blzt3hzvppKjgoGNl1G+GvO2YnZFV961+Cb1nO3vsbqc5Q1fsrzA IfQ/o0i6mJGYIv5mKd8S3QMEWioC1iG8s0D/o/DMDelyy7yQziGfuWe5D1LYf6g1AP3x g/fQ== X-Gm-Message-State: AOJu0Yzk7mrmHKb4IMrfvuuSs7eOYI7z2HkV8rP1rltBNXN/8L4qPxLX iTnXxzRypxhRBF2R0VtrUiR3V1Uc/wkKchlc/8jlcw4XOILCvVveqQ9C/hrlsbT4ImPyQDgnGl3 tmTvpvlABFpnNq5Iv5rMck6IakrRC/qfEog== X-Gm-Gg: ASbGncu1HRK06tg5Ls6eki/Pbb45SJjRAuTc9PHOpjBnqkILWTw+QwCTnDP7Xz9gUGk Iw65+M+YefTQKLvo4bW+KsIy2aypj9RqHVv2dhBfSk8ENkyUp/KSFsx48739Y+6SO9vckimnO/N m071PWCa3YYMYT+1pTvPpksInd58ngUHenNU8= X-Google-Smtp-Source: AGHT+IGrIZBd6BNqLAEXgBE6MA6Fh/z+qbVMyCpNpKboxU9ur3XfGLUqKJGIWNB4Nx16m4+obL4WNACwPmN2L4xJwm0= X-Received: by 2002:a05:6122:da2:b0:525:bf40:e628 with SMTP id 71dfb90a1353d-52dba90fdc7mr22407170e0c.6.1747914449853; Thu, 22 May 2025 04:47:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ship Mints Date: Thu, 22 May 2025 07:47:18 -0400 X-Gm-Features: AX0GCFvcNtP1jsCqSvJTifdXGagmftKEI_CM5qwuWQjwH63EFlWnLNnroY9e-fo Message-ID: Subject: Re: bug#78545: 31.0.50; project-mode-line is slow because it tries to read files on each update To: Yikai Zhao Content-Type: multipart/alternative; boundary="000000000000e1ac4c0635b80bf1" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78545 Cc: 78545@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000e1ac4c0635b80bf1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 22, 2025 at 2:17=E2=80=AFAM Yikai Zhao wrote: > After enabling `project-mode-line`, I find my emacs slightly less > responsive. I think it's because project-mode-line is slow due to > it trying to read files on each update. Here's how I reproduce it: > > - Run `emacs -Q` > - Evaluate `(setopt project-mode-line t)` > - Open some random file in a non-project directory, e.g. `/tmp/test`, > start typing > > Here's part of the profiling result: > > 114 62% - redisplay_internal (C function) > 42 23% - eval > 41 22% - project-mode-line-format > 41 22% - project-current > 41 22% - project--find-in-directory > 41 22% - run-hook-with-args-until-success > 41 22% - project-try-vc > 41 22% - project-try-vc--search > 25 13% - project--value-in-dir > 22 12% - hack-dir-local-variables > 22 12% - # > 22 12% - hack-dir-local--get-variables > 22 12% - dir-locals-find-file > 22 12% - locate-dominating-file > 12 6% + abbreviate-file-name > 3 1% + # > 13 7% - locate-dominating-file > 6 3% + # > 3 1% abbreviate-file-name > 3 1% > > It shows that `project-mode-line-format` can take a significant portion > of the redisplay time. It increases even more when the directory is deep > or the disk is slow. > > IMO the performance of this function should be improved. > > I have two questions: > > 1. Is it possible to simply cache the result as buffer-local? > 2. IIUC some of the file reading comes from `project--value-in-dir`, > which opens a temporary buffer to load dir local variables. Why doesn't > it simply read the variable value in the current buffer? > I've advised project functions to cache the "invariants" current project and project root to incur these costs once per buffer. I also cache the nuance of a "non project" to avoid repeated project probing on buffers that don't have a project. I thought maybe I was the only person silly enough to invoke costly project functions for every tab in `tab-bar` and every mode-line update. I could contribute optional caching to project.el if there is sufficient demand for it. Unless someone else wants to. --000000000000e1ac4c0635b80bf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Thu, May 22, 2025 at 2:17=E2=80=AFAM Yikai Zhao <yikai@z1k.dev> wrote:
After enabling `project-mode-line`, I find my emacs slightly les= s
responsive. I think it's because project-mode-line is slow due to
it trying to read files on each update. Here's how I reproduce it:

- Run `emacs -Q`
- Evaluate `(setopt project-mode-line t)`
- Open some random file in a non-project directory, e.g. `/tmp/test`,
start typing

Here's part of the profiling result:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0114=C2=A0 62% - redisplay_internal (C fun= ction)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 42=C2=A0 23%=C2=A0 - eval
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 41=C2=A0 22%=C2=A0 =C2=A0- project-mode-= line-format
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 41=C2=A0 22%=C2=A0 =C2=A0 - project-curr= ent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 41=C2=A0 22%=C2=A0 =C2=A0 =C2=A0- projec= t--find-in-directory
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 41=C2=A0 22%=C2=A0 =C2=A0 =C2=A0 - run-h= ook-with-args-until-success
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 41=C2=A0 22%=C2=A0 =C2=A0 =C2=A0 =C2=A0-= project-try-vc
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 41=C2=A0 22%=C2=A0 =C2=A0 =C2=A0 =C2=A0 = - project-try-vc--search
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 25=C2=A0 13%=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0- project--value-in-dir
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22=C2=A0 12%=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 - hack-dir-local-variables
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22=C2=A0 12%=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0- #<byte-code-function 24E>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22=C2=A0 12%=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - hack-dir-local--get-variables
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22=C2=A0 12%=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0- dir-locals-find-file
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22=C2=A0 12%=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 - locate-dominating-file
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12=C2=A0 =C2=A06%=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ abbreviate-file-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03=C2=A0 =C2=A01%=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 + #<byte-code-function 98F>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13=C2=A0 =C2=A07%=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0- locate-dominating-file
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06=C2=A0 =C2=A03%=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 + #<byte-code-function 4D9>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03=C2=A0 =C2=A01%=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 abbreviate-file-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03=C2=A0 =C2=A01%

It shows that `project-mode-line-format` can take a significant portion
of the redisplay time. It increases even more when the directory is deep or the disk is slow.

IMO the performance of this function should be improved.

I have two questions:

1. Is it possible to simply cache the result as buffer-local?
2. IIUC some of the file reading comes from `project--value-in-dir`,
which opens a temporary buffer to load dir local variables. Why doesn't=
it simply read the variable value in the current buffer?

I= 've advised project functions to cache the "invariants" curre= nt project and project root to incur these costs once per buffer.=C2=A0 I a= lso cache the nuance of a "non project" to avoid repeated project= probing on buffers that don't have a project.

I thought maybe I was the only person= silly enough to invoke costly project functions for every tab in `tab-bar`= and every mode-line update.

I could contribute optional caching to project.el if there = is sufficient demand for it.=C2=A0 Unless someone else wants to.
--000000000000e1ac4c0635b80bf1-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 22 11:54:59 2025 Received: (at 78545) by debbugs.gnu.org; 22 May 2025 15:55:00 +0000 Received: from localhost ([127.0.0.1]:36256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uI8G3-0004jj-Fg for submit@debbugs.gnu.org; Thu, 22 May 2025 11:54:59 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:54974) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uI8Fr-0004ia-Qy for 78545@debbugs.gnu.org; Thu, 22 May 2025 11:54:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dTTZ/dFbLxmawfrRhUhRTK5OSp+5xlMBGpnkjiCZFhk=; b=PwKfNdAjlInQJ6KwLvPWu7iTlS Wz1Q4hJMTNOMcSXSVy58QPnHozo0yjBb4B8sWVpeNIOGApUy59EqBA6k0TTrzDVibQhtMhKGLgKJO A6Q6ttIYGXdoFUc4PkqwIXXYN55FMWQhijwE98yE4BZnbTHtALJnlZKwaq968PvaE9XkJP1ae0B7A Qt9AyLuZOC6yTDLzFyB9XDiwuqmJl5408ijJ70Cqq92ETVDqxSOGzx8O3eNhdHW3qo3qGX7uxwPo1 gwdjqgNceFisSFb8JLUWzFr+5XCcyjFarj/gE3PsLRI/XNOKXX2/1BGzAP2yO7svBaoo9BOwj9g6j 2nrFfuTg==; Received: from 2603-9001-4203-1ab2-a4db-cc40-dc15-f259.inf6.spectrum.com ([2603:9001:4203:1ab2:a4db:cc40:dc15:f259]:42246 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uI8Ek-00AFER-1U; Thu, 22 May 2025 11:53:38 -0400 Date: Thu, 22 May 2025 11:53:57 -0400 From: Daniel Colascione To: bug-gnu-emacs@gnu.org, Ship Mints , Yikai Zhao Subject: =?US-ASCII?Q?Re=3A_bug=2378545=3A_31=2E0=2E50=3B_project-mode-line_is_sl?= =?US-ASCII?Q?ow_because_it_tries_to_read_files_on_each_update?= User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <14B95357-B1E5-4301-AFF9-B5658EDE532E@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 78545 Cc: 78545@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On May 22, 2025 7:47:18 AM EDT, Ship Mints wrote: >On Thu, May 22, 2025 at 2:17=E2=80=AFAM Yikai Zhao wrot= e: > >> After enabling `project-mode-line`, I find my emacs slightly less >> responsive=2E I think it's because project-mode-line is slow due to >> it trying to read files on each update=2E Here's how I reproduce it: >> >> - Run `emacs -Q` >> - Evaluate `(setopt project-mode-line t)` >> - Open some random file in a non-project directory, e=2Eg=2E `/tmp/test= `, >> start typing >> >> Here's part of the profiling result: >> >> 114 62% - redisplay_internal (C function) >> 42 23% - eval >> 41 22% - project-mode-line-format >> 41 22% - project-current >> 41 22% - project--find-in-directory >> 41 22% - run-hook-with-args-until-success >> 41 22% - project-try-vc >> 41 22% - project-try-vc--search >> 25 13% - project--value-in-dir >> 22 12% - hack-dir-local-variables >> 22 12% - # >> 22 12% - hack-dir-local--get-variables >> 22 12% - dir-locals-find-file >> 22 12% - locate-dominating-file >> 12 6% + abbreviate-file-name >> 3 1% + # >> 13 7% - locate-dominating-file >> 6 3% + # >> 3 1% abbreviate-file-name >> 3 1% >> >> It shows that `project-mode-line-format` can take a significant portion >> of the redisplay time=2E It increases even more when the directory is d= eep >> or the disk is slow=2E >> >> IMO the performance of this function should be improved=2E >> >> I have two questions: >> >> 1=2E Is it possible to simply cache the result as buffer-local? >> 2=2E IIUC some of the file reading comes from `project--value-in-dir`, >> which opens a temporary buffer to load dir local variables=2E Why doesn= 't >> it simply read the variable value in the current buffer? >> > >I've advised project functions to cache the "invariants" current project >and project root to incur these costs once per buffer=2E I also cache th= e >nuance of a "non project" to avoid repeated project probing on buffers th= at >don't have a project=2E > >I thought maybe I was the only person silly enough to invoke costly proje= ct >functions for every tab in `tab-bar` and every mode-line update=2E > >I could contribute optional caching to project=2Eel if there is sufficien= t >demand for it=2E Unless someone else wants to=2E We could also just have the IO functions signal error if called during a m= ode line update=2E From debbugs-submit-bounces@debbugs.gnu.org Thu May 22 11:58:27 2025 Received: (at 78545) by debbugs.gnu.org; 22 May 2025 15:58:27 +0000 Received: from localhost ([127.0.0.1]:36291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uI8JP-00052r-AR for submit@debbugs.gnu.org; Thu, 22 May 2025 11:58:27 -0400 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]:42185) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uI8JK-00052B-Tu for 78545@debbugs.gnu.org; Thu, 22 May 2025 11:58:23 -0400 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-551f0072119so43723e87.0 for <78545@debbugs.gnu.org>; Thu, 22 May 2025 08:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747929496; x=1748534296; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :from:to:cc:subject:date:message-id:reply-to; bh=KWhtOrXg7TJFcLbKJK+La+Fmle2MgbWX+iJGHjF/JGk=; b=CzYSHrNcLhGLhfwyw0qicksyZ3j3Ik4t/aMEwOMC89jXGDDPc2GA0Lhfcf5hNJnMLK SxQVl7w/inaXyRErPXtjZVEztdWOaiKqZnKJ4HPG1YL4+H1A4nTpVyhuWjNxGkPugJH2 e0o8m2ymdpzjS7n9ePyTMKSTzRNLE5j1MhgFwIeDMZK7/3x6KrS+RYvwXh6pd7FFQVnD ysmTqRA3g84fOZmEDNzh31lYGALWD2GFl7k0YM2t4ptYfJPsw1JnsDttIdFr9MXTLUWq qwAXpEWMo5vk2lFpDRPtcv05mHze11++iNjMNeJcoKBd7f4sJMmAkGZ4Pc6XseimJQW7 Lulw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747929496; x=1748534296; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KWhtOrXg7TJFcLbKJK+La+Fmle2MgbWX+iJGHjF/JGk=; b=xDiGpzzEjSxfL+n5MKQIl5MOuObIWYmOBeXIZ6Ow8zEjLu0XVMJRleXRO8B1xb6UXN ZJ2UbBk3RU+OxWKgC+xnGZo76uPL0mfC4RkdqhJeRQBA0PLO6lDZDVZ/ufZBhrmIGbk/ 97j62YPc8nIpLe3AuK5wzvYTdOvbbS4n8KZZWAF7StQsEI7c0LVMXzqUaTgKHLkfSMgJ 45KdbEtZUzpNDY5zS1X06IFujporhWssf0wcLE80LmAGQn7luMaIzvVDH1X/pDgR81Ih 17WxvC6kQdrPRr0sAIPzbaSOXJYZ+tkgh5wnJnaNbkxLcOivaX1a5vMZyDEqi27YpKOQ 5IFw== X-Forwarded-Encrypted: i=1; AJvYcCVJ9L9/7iNOe5h/hIBt/iV6aqsULjtqhEkP0186Tdm7KV5i5OApOrDctYyAqsDJSFsDV4ydrw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YznNGqsKOfh1ypcjVmM+9TEIp1jOqy86XaNhlAWqF44/SVpQXJt bskhRfiDY/df9uAIAz4yoAvIg3b6v7DOlWOEiS57wycEj2TgrkgKUZTMjTzNS38JfabdUbjgRCj z9RwqHJ+h/GWdZXpE6URiqFkv21ZcXUo= X-Gm-Gg: ASbGncuX3v2zFQuxT4YoxVqt/wE0PLJ2HnnJTEs/Ny5cmB13Ot6WQraMEyAGOEUNGZ4 qYSmEmA+onS2cYUkSWXhVaNYJczM77hp7DLdiylw/Ntr7XtgKSVNIxv5aARHU1MP5VCPiOPb2wu O47I5YWCpy586bcSsXgowDsrc6WUrXrVmFt0b95YsjM3M= X-Google-Smtp-Source: AGHT+IFQ6NhmlMZvVg20fE8uodVKV89fP7EUZ85bCRoiHZfvtVR+jY/VtnbfSHWDtWBkAVKRUggI17b1sbGt+LSTLQQ= X-Received: by 2002:a05:6512:228a:b0:54a:cc10:1050 with SMTP id 2adb3069b0e04-550e74b46f1mr8421620e87.15.1747929495778; Thu, 22 May 2025 08:58:15 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 22 May 2025 08:58:15 -0700 Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 22 May 2025 08:58:15 -0700 From: Kristoffer Balintona In-Reply-To: References: MIME-Version: 1.0 Date: Thu, 22 May 2025 08:58:15 -0700 X-Gm-Features: AX0GCFsvNvb8eZpzqxEs_F9MyCS4bq44rKg5g-91L3A8IW9InCkZ4MbRt104QTw Message-ID: Subject: Re: bug#78545: 31.0.50; project-mode-line is slow because it tries to read files on each update To: Yikai Zhao , 78545@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78545 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, May 22 2025, Yikai Zhao wrote: > After enabling `project-mode-line`, I find my emacs slightly less > responsive. I think it's because project-mode-line is slow due to > it trying to read files on each update. Here's how I reproduce it: > > - Run `emacs -Q` > - Evaluate `(setopt project-mode-line t)` > - Open some random file in a non-project directory, e.g. `/tmp/test`, > start typing > > Here's part of the profiling result: > > 114 62% - redisplay_internal (C function) > 42 23% - eval > 41 22% - project-mode-line-format > 41 22% - project-current > 41 22% - project--find-in-directory > 41 22% - run-hook-with-args-until-success > 41 22% - project-try-vc > 41 22% - project-try-vc--search > 25 13% - project--value-in-dir > 22 12% - hack-dir-local-variables > 22 12% - # > 22 12% - hack-dir-local--get-variables > 22 12% - dir-locals-find-file > 22 12% - locate-dominating-file > 12 6% + abbreviate-file-name > 3 1% + # > 13 7% - locate-dominating-file > 6 3% + # > 3 1% abbreviate-file-name > 3 1% > > It shows that `project-mode-line-format` can take a significant portion > of the redisplay time. It increases even more when the directory is deep > or the disk is slow. > > IMO the performance of this function should be improved. > > I have two questions: > > 1. Is it possible to simply cache the result as buffer-local? > 2. IIUC some of the file reading comes from `project--value-in-dir`, > which opens a temporary buffer to load dir local variables. Why doesn't > it simply read the variable value in the current buffer? > I experienced similar, actually, on Nix where the Emacs source files, having been built in the special Nix store, are somewhere deep under /nix/store/. I suspected it was project.el trying to find a root. I never got around to confirming it nor finding a fix. -- In gratitude, Kristoffer From debbugs-submit-bounces@debbugs.gnu.org Thu May 22 12:23:33 2025 Received: (at 78545) by debbugs.gnu.org; 22 May 2025 16:23:33 +0000 Received: from localhost ([127.0.0.1]:36462 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uI8hg-00073Q-H1 for submit@debbugs.gnu.org; Thu, 22 May 2025 12:23:33 -0400 Received: from mail-ua1-x934.google.com ([2607:f8b0:4864:20::934]:46129) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uI8hV-000729-5o for 78545@debbugs.gnu.org; Thu, 22 May 2025 12:23:28 -0400 Received: by mail-ua1-x934.google.com with SMTP id a1e0cc1a2514c-87bf51f7225so3221048241.0 for <78545@debbugs.gnu.org>; Thu, 22 May 2025 09:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747930995; x=1748535795; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AsZRXBlR1U/IlKYXUY+FaCA2bATf6uEzwtbH5NWkcnc=; b=BCR9fvL219QOXIBgcdCZEGqs7n8rVtkEIsgNeyJL21GuYH+prBfx4cI5eT6yqMCCvz 1ipXV/PSg9lEo19rDjWmrNEILGczf52cdo80va3F3hriTfzcrk13zMbJp4D6C0IsPTBt pnACkj5/JTT7G9HRnYnIk8Op5Wm38dOQtL71cQJOLKqzy6h6XYHCGD+PQpP0mDVt/8mY UC6cUnxcLLxftRe6tIDYxpyb+RAB6mtJWiF/KGewA4FblJTz8CXfSWhHOthx3eGI68RC nsdTvedkQcd7uiufNO2DmFgKhMwJUqSGqeiECR30EETXK6Nh7O5Rdek4kWS1cD+HVCm/ l8gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747930995; x=1748535795; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AsZRXBlR1U/IlKYXUY+FaCA2bATf6uEzwtbH5NWkcnc=; b=bBCJhYs0hi+wvNgJAIhIC1EbfpHmS7HR39xeiUaMY0N7W9qMfSO8d+QqEj1Ica5xwK feWd6h9I8LV86ksvaYT6+cXdk9VdQJqORGOCgLanYll7VJV4pwc5RwTq8AYIIQGB6OLJ yRRFzihe3x6hpeCseHhEvP7/CUsr/JjGMYc230R1bFmgjjlskyT05VFp6u8psCErMOTF AAJwe1NJSJDPW02ML1lzlVetu3k6s20fUcufKhiQIUl55NEeRy4LT3Q71WnY/nrYVBwg e1sDht277IYtmi6vDaJJf/3Zc6OAgLg90bQRHc2hb4FiS8VEDTeeeRfKQ6+Ez4z2bsBt V3Zg== X-Forwarded-Encrypted: i=1; AJvYcCXeU1Ro+MezNmCE0DBrwTpm/Mj5ABsPKScVx1zMWv/S5szSkQ6XEYv44NedT4tutV6mbivCqg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzE2qWQE3F7cOA4hobZWHI+CYfIY4sL2ajBjjNJEbpfqYS9Jc4r Ggm8vPMvpIgEzuOv7cBgqpKtJloWq7nP7LGzb/vuBKhxbSlnuBC6R2iKfry81WW5C3F03Aq2IgK 8WqlscGEdifdqI/BeTZ8Kw+0F9fYVTVs= X-Gm-Gg: ASbGnct+JMvnwL2FB35Sa+wNPqfBKmLQWf6gCAov9Hi5TI4rETQlw/YJoDAEcaCy6cQ OHCIbulekXPCUz/diEBOAdJGLHGVEcgNAkjZ1tDMsdQP75h9omyYxPZNHKtCVovfEJBX6IJcF2Z WnRDGA2tzJjX0OgoNrGmWUiavUlq0HQx5DDVw= X-Google-Smtp-Source: AGHT+IHpkne3pHepm6NBkowEcOzUtaJvSP6OeGe3HtKlvsu788F51xrBVM0rtJRelg+/1umh565degVKciWY+YVgcRU= X-Received: by 2002:a05:6102:3f9f:b0:4bb:e80b:473d with SMTP id ada2fe7eead31-4dfa6b6c352mr22976093137.6.1747930994854; Thu, 22 May 2025 09:23:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ship Mints Date: Thu, 22 May 2025 12:23:01 -0400 X-Gm-Features: AX0GCFvQjwu780cIsd8Q2BCbhySZKQuAIO0wh7_B9Rx9m0kKJGCpQbikghzVn9s Message-ID: Subject: Re: bug#78545: 31.0.50; project-mode-line is slow because it tries to read files on each update To: Kristoffer Balintona Content-Type: multipart/alternative; boundary="0000000000000a4f960635bbe614" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78545 Cc: Yikai Zhao , 78545@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000000a4f960635bbe614 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 22, 2025 at 11:59=E2=80=AFAM Kristoffer Balintona < krisbalintona@gmail.com> wrote: > On Thu, May 22 2025, Yikai Zhao wrote: > > > After enabling `project-mode-line`, I find my emacs slightly less > > responsive. I think it's because project-mode-line is slow due to > > it trying to read files on each update. Here's how I reproduce it: > > > > - Run `emacs -Q` > > - Evaluate `(setopt project-mode-line t)` > > - Open some random file in a non-project directory, e.g. `/tmp/test`, > > start typing > > > > Here's part of the profiling result: > > > > 114 62% - redisplay_internal (C function) > > 42 23% - eval > > 41 22% - project-mode-line-format > > 41 22% - project-current > > 41 22% - project--find-in-directory > > 41 22% - run-hook-with-args-until-success > > 41 22% - project-try-vc > > 41 22% - project-try-vc--search > > 25 13% - project--value-in-dir > > 22 12% - hack-dir-local-variables > > 22 12% - # > > 22 12% - hack-dir-local--get-variables > > 22 12% - dir-locals-find-file > > 22 12% - locate-dominating-file > > 12 6% + abbreviate-file-name > > 3 1% + # > > 13 7% - locate-dominating-file > > 6 3% + # > > 3 1% abbreviate-file-name > > 3 1% > > > > It shows that `project-mode-line-format` can take a significant portion > > of the redisplay time. It increases even more when the directory is dee= p > > or the disk is slow. > > > > IMO the performance of this function should be improved. > > > > I have two questions: > > > > 1. Is it possible to simply cache the result as buffer-local? > > 2. IIUC some of the file reading comes from `project--value-in-dir`, > > which opens a temporary buffer to load dir local variables. Why doesn't > > it simply read the variable value in the current buffer? > > > > I experienced similar, actually, on Nix where the Emacs source files, > having been built in the special Nix store, are somewhere deep under > /nix/store/. I suspected it was project.el trying to find a root. I > never got around to confirming it nor finding a fix. > I'm taking some time today to rework my approach rather than use advice. That was hacky, and good enough for personal use to scratch an immediate itch. If this comes out well, I'll propose a project.el patch and see what people think. Daniel, I'm not so sure about blocking all IO in mode-line updates. That sounds like it will surprise a lot of people. -Stephane --0000000000000a4f960635bbe614 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Thu, May 22, 2025 at 11:59=E2=80=AFAM Kristoffer Balintona <krisbalintona@gmail.com> wrote:<= /span>
On Thu, May 22 2025, Yikai Zhao w= rote:

> After enabling `project-mode-line`, I find my emacs slightly less
> responsive. I think it's because project-mode-line is slow due to<= br> > it trying to read files on each update. Here's how I reproduce it:=
>
> - Run `emacs -Q`
> - Evaluate `(setopt project-mode-line t)`
> - Open some random file in a non-project directory, e.g. `/tmp/test`,<= br> > start typing
>
> Here's part of the profiling result:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 114=C2=A0 62% - redisplay_internal (= C function)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A042=C2=A0 23%=C2=A0 - eval
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041=C2=A0 22%=C2=A0 =C2=A0- pro= ject-mode-line-format
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041=C2=A0 22%=C2=A0 =C2=A0 - pr= oject-current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041=C2=A0 22%=C2=A0 =C2=A0 =C2= =A0- project--find-in-directory
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041=C2=A0 22%=C2=A0 =C2=A0 =C2= =A0 - run-hook-with-args-until-success
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041=C2=A0 22%=C2=A0 =C2=A0 =C2= =A0 =C2=A0- project-try-vc
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041=C2=A0 22%=C2=A0 =C2=A0 =C2= =A0 =C2=A0 - project-try-vc--search
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A025=C2=A0 13%=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0- project--value-in-dir
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A022=C2=A0 12%=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 - hack-dir-local-variables
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A022=C2=A0 12%=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0- #<byte-code-function 24E>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A022=C2=A0 12%=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 - hack-dir-local--get-variables
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A022=C2=A0 12%=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- dir-locals-find-file
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A022=C2=A0 12%=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - locate-dominating-file
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A012=C2=A0 =C2=A06%=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ abbreviate-file-name
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3=C2=A0 =C2=A01%=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 + #<byte-code-function 98F>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013=C2=A0 =C2=A07%=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0- locate-dominating-file
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6=C2=A0 =C2=A03%=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 + #<byte-code-function 4D9>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3=C2=A0 =C2=A01%=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 abbreviate-file-name
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3=C2=A0 =C2=A01%
>
> It shows that `project-mode-line-format` can take a significant portio= n
> of the redisplay time. It increases even more when the directory is de= ep
> or the disk is slow.
>
> IMO the performance of this function should be improved.
>
> I have two questions:
>
> 1. Is it possible to simply cache the result as buffer-local?
> 2. IIUC some of the file reading comes from `project--value-in-dir`, > which opens a temporary buffer to load dir local variables. Why doesn&= #39;t
> it simply read the variable value in the current buffer?
>

I experienced similar, actually, on Nix where the Emacs source files,
having been built in the special Nix store, are somewhere deep under
/nix/store/. I suspected it was project.el trying to find a root. I
never got around to confirming it nor finding a fix.
<= br>
I'= ;m taking some time today to rework my approach rather than use advice.=C2= =A0 That was hacky, and good enough for personal use to scratch an immediat= e itch.=C2=A0 If this comes out well, I'll propose a project.el patch a= nd see what people think.

Daniel, I'm not so sure about blocking all IO in mode-line= updates.=C2=A0 That sounds like it will surprise a lot of people.

-Stephane
= --0000000000000a4f960635bbe614-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 22 13:02:36 2025 Received: (at submit) by debbugs.gnu.org; 22 May 2025 17:02:36 +0000 Received: from localhost ([127.0.0.1]:36831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uI9JT-00026s-VD for submit@debbugs.gnu.org; Thu, 22 May 2025 13:02:36 -0400 Received: from lists.gnu.org ([2001:470:142::17]:53302) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uI9JK-00025E-Eh for submit@debbugs.gnu.org; Thu, 22 May 2025 13:02:31 -0400 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 1uI9JC-0003dr-W4 for bug-gnu-emacs@gnu.org; Thu, 22 May 2025 13:02:19 -0400 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uI9JA-00082l-MA for bug-gnu-emacs@gnu.org; Thu, 22 May 2025 13:02:18 -0400 Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-3a365a6804eso3665319f8f.3 for ; Thu, 22 May 2025 10:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=z1k.dev; s=google; t=1747933334; x=1748538134; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WTZTn79E+EM667NFaY5bkgqYEdedNdxRLkSPnSqPFHw=; b=Zgu3Mr4ot8zbpNJ2InTOBAYNPvzJZD+ogSs8NogLbwyuMr/Jj084S2rtkS9DJ5+WCv 0oicWOARkZOk74EoQ8wWimZMVunbB+e7RJeXZB+erOiPMp0dkHWzfDXOqfg69JdoWFFM NogPvfHHgOh5o3Pc/EOBcLXDjqbBZfxdV5kC9TteUbreO57GqZhTyvrYgFhVkUTtuLEm shOCgMXtvbhpazWdBHOVxsOqOOPKX435fhJB1CtxmSvbrOFRT4Xn7cIrWZlp7TRUlycL Bv+iX3wCg8JnloFGLcRyiG1RDikkKgr+yK5IOyQk1kB2lEct08FUXHk8fyFa00dIaESs Kx9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747933334; x=1748538134; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WTZTn79E+EM667NFaY5bkgqYEdedNdxRLkSPnSqPFHw=; b=WolWrFS9uBULswhILWz+8vHjPMG2p5r5J64JzKvOfgiFFQLhYTC/FEYPlvlDe3USO9 7LLIfbymorEcmd6xUZGw9pfyMay49btQEuunob4cjfalGsfFXYs5Trfek5qa7gVgIY65 jtfliyarA6GaAcVi6e6ObgINn9LXhFENZePF8j0V7bfutFHgEnaptil31LtXF4t0xQZ/ LmCrx982plxL8IV0y4yEuz2SccCer1I6hCZysmJWiepmV4zu2zildpLRjsaxvhOJdHFN IO0sV3wVcgfqAErX8VyO9T27SJKzw5clJ3PucRNyH9VltjYSkwm68TiKNWTLXOIWLx7X PUEw== X-Gm-Message-State: AOJu0YzvG2mAMK+KKW5zz03K22VRj5x1qdJK5Xz1PihPPxsPz0FrDpic zwdUxOBGd2v9Wv8LGJzJaObjK4npYESos5SA7xvXgpU8jWUp75qp2rrrfAP3mb5vP7Cf+v/Eze2 BY6ko/XvdmGhv9zCTamo8ZJ0rX4HxzSU8mZ0J2bc53w== X-Gm-Gg: ASbGncsJPYE4ZTV01P3djvvQOBVcdnUP+7Qubb6bbfMpCXJHf6C1D7TZCkGMG2N7pNs rxHGwMbo+B9T/iw5E1dQcRR43FFP/ZQuqJ6qaQxhZfwGF58EmqcLQZoeSF5Lui/Z/tvm97Q16cx Ji5/Bn9HNGuT0qR+RnVpKQLnz+C7cG/QHXn5rm9UrTHUubGV6BtBfumvgUVZ0idSb9wIY= X-Google-Smtp-Source: AGHT+IFtrFWVi9TYVJpc7ePKGED2hApw+e+nHAQENF5F5bZU7g6ofQwLJzRsdZzRatKck3xNFjHdQOGZ1XB9QG2Z6P0= X-Received: by 2002:a5d:64ee:0:b0:3a0:b72a:b36 with SMTP id ffacd0b85a97d-3a35c84bd82mr22632094f8f.36.1747933334035; Thu, 22 May 2025 10:02:14 -0700 (PDT) MIME-Version: 1.0 References: <14B95357-B1E5-4301-AFF9-B5658EDE532E@dancol.org> In-Reply-To: <14B95357-B1E5-4301-AFF9-B5658EDE532E@dancol.org> From: Yikai Zhao Date: Fri, 23 May 2025 01:02:02 +0800 X-Gm-Features: AX0GCFsHUq8LjzkPbRjWJG6RigaqUN0PmpzoyiFav8W85nqwwzuKh8w83yz3DEw Message-ID: Subject: Re: bug#78545: 31.0.50; project-mode-line is slow because it tries to read files on each update To: Daniel Colascione Content-Type: multipart/alternative; boundary="0000000000007777600635bc7173" Received-SPF: pass client-ip=2a00:1450:4864:20::430; envelope-from=i@blahgeek.com; helo=mail-wr1-x430.google.com X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org, 78545@debbugs.gnu.org, Ship Mints X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --0000000000007777600635bc7173 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 22, 2025 at 23:54 Daniel Colascione wrote: > > > On May 22, 2025 7:47:18 AM EDT, Ship Mints wrote: > >On Thu, May 22, 2025 at 2:17=E2=80=AFAM Yikai Zhao wrote= : > > > >> After enabling `project-mode-line`, I find my emacs slightly less > >> responsive. I think it's because project-mode-line is slow due to > >> it trying to read files on each update. Here's how I reproduce it: > >> > >> - Run `emacs -Q` > >> - Evaluate `(setopt project-mode-line t)` > >> - Open some random file in a non-project directory, e.g. `/tmp/test`, > >> start typing > >> > >> Here's part of the profiling result: > >> > >> 114 62% - redisplay_internal (C function) > >> 42 23% - eval > >> 41 22% - project-mode-line-format > >> 41 22% - project-current > >> 41 22% - project--find-in-directory > >> 41 22% - run-hook-with-args-until-success > >> 41 22% - project-try-vc > >> 41 22% - project-try-vc--search > >> 25 13% - project--value-in-dir > >> 22 12% - hack-dir-local-variables > >> 22 12% - # > >> 22 12% - hack-dir-local--get-variables > >> 22 12% - dir-locals-find-file > >> 22 12% - locate-dominating-file > >> 12 6% + abbreviate-file-name > >> 3 1% + # > >> 13 7% - locate-dominating-file > >> 6 3% + # > >> 3 1% abbreviate-file-name > >> 3 1% > >> > >> It shows that `project-mode-line-format` can take a significant portio= n > >> of the redisplay time. It increases even more when the directory is de= ep > >> or the disk is slow. > >> > >> IMO the performance of this function should be improved. > >> > >> I have two questions: > >> > >> 1. Is it possible to simply cache the result as buffer-local? > >> 2. IIUC some of the file reading comes from `project--value-in-dir`, > >> which opens a temporary buffer to load dir local variables. Why doesn'= t > >> it simply read the variable value in the current buffer? > >> > > > >I've advised project functions to cache the "invariants" current project > >and project root to incur these costs once per buffer. I also cache the > >nuance of a "non project" to avoid repeated project probing on buffers > that > >don't have a project. > > > >I thought maybe I was the only person silly enough to invoke costly > project > >functions for every tab in `tab-bar` and every mode-line update. > > > >I could contribute optional caching to project.el if there is sufficient > >demand for it. Unless someone else wants to. > > We could also just have the IO functions signal error if called during a > mode line update. Personally I think this is a great idea. Aside from mode line updates, IO functions can cause undesired delay in many other functions (like tab bar or maybe post command hook). If we have a general way to mark certain hooks as =E2=80=9Cshould not block by IO=E2=80=9D and be able to capture those vi= olations, it would be very helpful. Yikai > --0000000000007777600635bc7173 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 22, 2025 at 23:54 Daniel Co= lascione <dancol@dancol.org>= wrote:


On May 22, 2025 7:47:18 AM EDT, Ship Mints <shipmints@gmail.com> wrote:
>On Thu, May 22, 2025 at 2:17=E2=80=AFAM Yikai Zhao <yikai@z1k.dev> wrote:
>
>> After enabling `project-mode-line`, I find my emacs slightly less<= br> >> responsive. I think it's because project-mode-line is slow due= to
>> it trying to read files on each update. Here's how I reproduce= it:
>>
>> - Run `emacs -Q`
>> - Evaluate `(setopt project-mode-line t)`
>> - Open some random file in a non-project directory, e.g. `/tmp/tes= t`,
>> start typing
>>
>> Here's part of the profiling result:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 114=C2=A0 62% - redisplay_intern= al (C function)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A042=C2=A0 23%=C2=A0 - eval<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041=C2=A0 22%=C2=A0 =C2=A0-= project-mode-line-format
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041=C2=A0 22%=C2=A0 =C2=A0 = - project-current
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041=C2=A0 22%=C2=A0 =C2=A0 = =C2=A0- project--find-in-directory
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041=C2=A0 22%=C2=A0 =C2=A0 = =C2=A0 - run-hook-with-args-until-success
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041=C2=A0 22%=C2=A0 =C2=A0 = =C2=A0 =C2=A0- project-try-vc
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041=C2=A0 22%=C2=A0 =C2=A0 = =C2=A0 =C2=A0 - project-try-vc--search
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A025=C2=A0 13%=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0- project--value-in-dir
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A022=C2=A0 12%=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 - hack-dir-local-variables
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A022=C2=A0 12%=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0- #<byte-code-function 24E>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A022=C2=A0 12%=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 - hack-dir-local--get-variables
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A022=C2=A0 12%=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- dir-locals-find-file
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A022=C2=A0 12%=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - locate-dominating-file
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A012=C2=A0 =C2=A06%=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ abbreviate-file-name
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3=C2=A0 =C2=A01%=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 + #<byte-code-function 98F>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013=C2=A0 =C2=A07%=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0- locate-dominating-file
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6=C2=A0 =C2=A03%=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 + #<byte-code-function 4D9>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3=C2=A0 =C2=A01%=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 abbreviate-file-name
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3=C2=A0 =C2=A01%
>>
>> It shows that `project-mode-line-format` can take a significant po= rtion
>> of the redisplay time. It increases even more when the directory i= s deep
>> or the disk is slow.
>>
>> IMO the performance of this function should be improved.
>>
>> I have two questions:
>>
>> 1. Is it possible to simply cache the result as buffer-local?
>> 2. IIUC some of the file reading comes from `project--value-in-dir= `,
>> which opens a temporary buffer to load dir local variables. Why do= esn't
>> it simply read the variable value in the current buffer?
>>
>
>I've advised project functions to cache the "invariants" = current project
>and project root to incur these costs once per buffer.=C2=A0 I also cac= he the
>nuance of a "non project" to avoid repeated project probing o= n buffers that
>don't have a project.
>
>I thought maybe I was the only person silly enough to invoke costly pro= ject
>functions for every tab in `tab-bar` and every mode-line update.
>
>I could contribute optional caching to project.el if there is sufficien= t
>demand for it.=C2=A0 Unless someone else wants to.

We could also just have the IO functions signal error if called during a mo= de line update.

P= ersonally I think this is a great idea. Aside from mode line updates, IO fu= nctions can cause undesired delay in=C2=A0many other functions (like tab ba= r or maybe post command hook). If we have a general way to mark certain hoo= ks as =E2=80=9Cshould not block by IO=E2=80=9D and be able to capture those= violations,=C2=A0it would be very helpful.=C2=A0

Yikai


--0000000000007777600635bc7173-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 22 13:21:38 2025 Received: (at submit) by debbugs.gnu.org; 22 May 2025 17:21:38 +0000 Received: from localhost ([127.0.0.1]:37038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uI9bu-0004Af-Ch for submit@debbugs.gnu.org; Thu, 22 May 2025 13:21:38 -0400 Received: from lists.gnu.org ([2001:470:142::17]:37298) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uI9br-00049b-Ov for submit@debbugs.gnu.org; Thu, 22 May 2025 13:21:36 -0400 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 1uI9bl-0001w4-Pm for bug-gnu-emacs@gnu.org; Thu, 22 May 2025 13:21:29 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uI9bi-0003fc-Hp for bug-gnu-emacs@gnu.org; Thu, 22 May 2025 13:21:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=OEW2nYaueL/DEkqhNY4HMRFwaZYEgK26hnvh/m8o74c=; b=k3UEaX/sGUdkbaMT/2BYUMxxBO oTTMFvt5OxQJDHp+5tcZTDFi75pWa6y51M0C3aE71F0YkP3okFk3qzQD75UuoI1PAGHlcdZzFx7U6 QMVhRYXwviI15NsNb3K9ig7+oEUnLvzlQQCoC0ZzGY3k2//dc/rmDx7Jq4pmDLjX7dAXQ+g/hoHAr iWe8hc1iwB4mlsiMyktq70XnFwqZogoIrcztUcgBNCywtlL6HQymlbQ4xylAQ+w6heXcbvjXCnVjx kBXneEoY9h8PMvH+DX00g/VSTeaWjvOtB3VCkkIES2UKzItksfoC3VfMgwlgC8WgdAMT3V5Apire6 /aMdrIWA==; Received: from [2600:1006:b19d:16b2:0:50:482a:bd01] (port=50326 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uI9ac-00AFZD-2r; Thu, 22 May 2025 13:20:19 -0400 Date: Thu, 22 May 2025 13:21:18 -0400 From: Daniel Colascione To: Yikai Zhao Subject: =?US-ASCII?Q?Re=3A_bug=2378545=3A_31=2E0=2E50=3B_project-mode-line_is_sl?= =?US-ASCII?Q?ow_because_it_tries_to_read_files_on_each_update?= User-Agent: K-9 Mail for Android In-Reply-To: References: <14B95357-B1E5-4301-AFF9-B5658EDE532E@dancol.org> Message-ID: <0943DFD3-DDCE-486F-831D-8AAA3E43BE6C@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org, 78545@debbugs.gnu.org, Ship Mints X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) On May 22, 2025 1:02:02 PM EDT, Yikai Zhao wrote: >On Thu, May 22, 2025 at 23:54 Daniel Colascione wro= te: > >> >> >> On May 22, 2025 7:47:18 AM EDT, Ship Mints wrot= e: >> >On Thu, May 22, 2025 at 2:17=E2=80=AFAM Yikai Zhao w= rote: >> > >> >> After enabling `project-mode-line`, I find my emacs slightly less >> >> responsive=2E I think it's because project-mode-line is slow due to >> >> it trying to read files on each update=2E Here's how I reproduce it: >> >> >> >> - Run `emacs -Q` >> >> - Evaluate `(setopt project-mode-line t)` >> >> - Open some random file in a non-project directory, e=2Eg=2E `/tmp/t= est`, >> >> start typing >> >> >> >> Here's part of the profiling result: >> >> >> >> 114 62% - redisplay_internal (C function) >> >> 42 23% - eval >> >> 41 22% - project-mode-line-format >> >> 41 22% - project-current >> >> 41 22% - project--find-in-directory >> >> 41 22% - run-hook-with-args-until-success >> >> 41 22% - project-try-vc >> >> 41 22% - project-try-vc--search >> >> 25 13% - project--value-in-dir >> >> 22 12% - hack-dir-local-variables >> >> 22 12% - # >> >> 22 12% - hack-dir-local--get-variables >> >> 22 12% - dir-locals-find-file >> >> 22 12% - locate-dominating-file >> >> 12 6% + abbreviate-file-name >> >> 3 1% + # >> >> 13 7% - locate-dominating-file >> >> 6 3% + # >> >> 3 1% abbreviate-file-name >> >> 3 1% >> >> >> >> It shows that `project-mode-line-format` can take a significant port= ion >> >> of the redisplay time=2E It increases even more when the directory i= s deep >> >> or the disk is slow=2E >> >> >> >> IMO the performance of this function should be improved=2E >> >> >> >> I have two questions: >> >> >> >> 1=2E Is it possible to simply cache the result as buffer-local? >> >> 2=2E IIUC some of the file reading comes from `project--value-in-dir= `, >> >> which opens a temporary buffer to load dir local variables=2E Why do= esn't >> >> it simply read the variable value in the current buffer? >> >> >> > >> >I've advised project functions to cache the "invariants" current proje= ct >> >and project root to incur these costs once per buffer=2E I also cache= the >> >nuance of a "non project" to avoid repeated project probing on buffers >> that >> >don't have a project=2E >> > >> >I thought maybe I was the only person silly enough to invoke costly >> project >> >functions for every tab in `tab-bar` and every mode-line update=2E >> > >> >I could contribute optional caching to project=2Eel if there is suffic= ient >> >demand for it=2E Unless someone else wants to=2E >> >> We could also just have the IO functions signal error if called during = a >> mode line update=2E > > >Personally I think this is a great idea=2E Aside from mode line updates, = IO >functions can cause undesired delay in many other functions (like tab bar >or maybe post command hook)=2E If we have a general way to mark certain h= ooks >as =E2=80=9Cshould not block by IO=E2=80=9D and be able to capture those = violations, it >would be very helpful=2E I've been meaning to write a slow hook detector for a few weeks now=2E Fee= l free to beat me to it=2E I figure we can start by just calling each entry= in the major hooks with a new run hooks (with args) variant that records t= imes of each and reports anything over a threshold as a warning=2E > > >Yikai > > >> From debbugs-submit-bounces@debbugs.gnu.org Thu May 22 15:25:21 2025 Received: (at 78545) by debbugs.gnu.org; 22 May 2025 19:25:21 +0000 Received: from localhost ([127.0.0.1]:38353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uIBXd-0006dg-EY for submit@debbugs.gnu.org; Thu, 22 May 2025 15:25:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33024) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uIBXb-0006c7-4K for 78545@debbugs.gnu.org; Thu, 22 May 2025 15:25:19 -0400 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 1uIBXU-0001QK-AW; Thu, 22 May 2025 15:25:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=R+EfsYaUHJCP99TZh9L2sKmQjbjlrCBu61W/gsk0RGY=; b=Bc/GEgwFOwMQ6IumE3cT k9YQkPET8qJtMTXdv+xtfSUg3xC/62Ozuof2Uv351atV7IuXwCGdDy7O1U50qq/Ft+33hvcfqkfZd 4i1S1YweyLSiuH7dSvl45l3QNfHhSLRRN+C+U9mqMQM8S956khIoE7tzHXNNR9lZtAybsdscl7gJA qpRPy1XCfcSaFNvrQLMRjBEYOfAGLtjfbSVt1QiIVG+ipXG+UweD+BxJ4DcuKMpmvSMB+QoG5vDGX TXo01SR6uOTZX6ZKVcT8mwxGBOBJF87gnEvgHmX426sAsGk8n6o5P+GAmuJoqUroovVBhikyZqcD2 iz4xPq1ES9KwyQ==; Date: Thu, 22 May 2025 22:25:05 +0300 Message-Id: <86frgw5tym.fsf@gnu.org> From: Eli Zaretskii To: Yikai Zhao In-Reply-To: (message from Yikai Zhao on Fri, 23 May 2025 01:02:02 +0800) Subject: Re: bug#78545: 31.0.50; project-mode-line is slow because it tries to read files on each update References: <14B95357-B1E5-4301-AFF9-B5658EDE532E@dancol.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78545 Cc: dancol@dancol.org, 78545@debbugs.gnu.org, shipmints@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 78545@debbugs.gnu.org, shipmints@gmail.com > From: Yikai Zhao > Date: Fri, 23 May 2025 01:02:02 +0800 > > We could also just have the IO functions signal error if called during a mode line update. > > Personally I think this is a great idea. Aside from mode line updates, IO functions can cause undesired delay > in many other functions (like tab bar or maybe post command hook). If we have a general way to mark > certain hooks as “should not block by IO” and be able to capture those violations, it would be very helpful. Signaling an error inside redisplay is not useful. It just writes a message into *Messages* and that's it. Unless you are very vigilant, it will take you a long time to even look in *Messages* and realize Emacs signaled that error. If a function doesn't want to do its job in some situation, it should return without doing anything, rather than signaling an error. Besides, I see nothing wrong with calling from redisplay functions that access the filesystem, not in general, anyway. Sure, calling locate-dominating-file from a deep directory is not a very wise thing to do as part of updating the mode line, but Emacs always gives us enough rope to hang ourselves, trusting us that we won't. We should live up to that trust by not doing silly things. From debbugs-submit-bounces@debbugs.gnu.org Thu May 22 15:28:19 2025 Received: (at 78545) by debbugs.gnu.org; 22 May 2025 19:28:19 +0000 Received: from localhost ([127.0.0.1]:38393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uIBaV-0006sj-5M for submit@debbugs.gnu.org; Thu, 22 May 2025 15:28:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55744) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uIBaR-0006s5-N9 for 78545@debbugs.gnu.org; Thu, 22 May 2025 15:28:16 -0400 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 1uIBaL-00025S-Qb; Thu, 22 May 2025 15:28: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=CsZgpQHRvC0WtdWNqo5sERti4NzNyTwyRfei1oJjjtk=; b=r4JBvkohYajf 7eM/5UPHJqLoYVOKb4RAJaP0EUNhRZQRX0T28lTUoM98XMNr4SOfLzlAFGLTAsPFlD2N5LDbkGJAt giMPN4ob4vlpC2Bj+OhwfVSzq0BSqwb+Qzukrg6z6Dqs5exjU/U9XqhECr+o5tK2TVXPLFCW2VnzR dKNfUUoAT41MxfPwZa2NSiqo0GYGSfRmqKgvXLqZTZlQK8NEySuWoqb7Dkr2/lFc6lXeCQKTFC3Xn TZD68nTJyKPND9PF9I0Zs0+PpsyeSkNKSTaDuXEiH50fQfYHFU3NUCTCNxUB5GBKaq9VTAJXenlUO BC+A/6XNZZGQjS4YEJ8Sgw==; Date: Thu, 22 May 2025 22:28:07 +0300 Message-Id: <86ecwg5ttk.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: <0943DFD3-DDCE-486F-831D-8AAA3E43BE6C@dancol.org> (message from Daniel Colascione on Thu, 22 May 2025 13:21:18 -0400) Subject: Re: bug#78545: 31.0.50; project-mode-line is slow because it tries to read files on each update References: <14B95357-B1E5-4301-AFF9-B5658EDE532E@dancol.org> <0943DFD3-DDCE-486F-831D-8AAA3E43BE6C@dancol.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78545 Cc: yikai@z1k.dev, 78545@debbugs.gnu.org, shipmints@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 78545@debbugs.gnu.org, shipmints@gmail.com > Date: Thu, 22 May 2025 13:21:18 -0400 > From: Daniel Colascione > > I've been meaning to write a slow hook detector for a few weeks now. Feel free to beat me to it. I figure we can start by just calling each entry in the major hooks with a new run hooks (with args) variant that records times of each and reports anything over a threshold as a warning. I think that would be a very useful feature. But it won't find this particular problem, because project.el doesn't use a hook to update the mode line in this case. From debbugs-submit-bounces@debbugs.gnu.org Thu May 22 20:37:44 2025 Received: (at 78545) by debbugs.gnu.org; 23 May 2025 00:37:44 +0000 Received: from localhost ([127.0.0.1]:40980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uIGPr-00080H-NX for submit@debbugs.gnu.org; Thu, 22 May 2025 20:37:43 -0400 Received: from fout-b2-smtp.messagingengine.com ([202.12.124.145]:36093) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uIGPk-0007zT-MW for 78545@debbugs.gnu.org; Thu, 22 May 2025 20:37:37 -0400 Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id 496B0114013F; Thu, 22 May 2025 20:37:26 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Thu, 22 May 2025 20:37:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=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:subject:subject:to:to; s=fm2; t=1747960646; x=1748047046; bh=ckvYx8LB+QYM7njWOYSsBZwube7gbqhZ6RvbHeDG/r4=; b= XtvYPWZbcZq7qGU5KDacMkG/sBxY/pQ0c5UL8dG93XReqzJybXhcfqg/zk8GHMrG Ct1L7pwWn6HcqJwUrWjLaSqY6CwIxYc6nSLDoVrDOUgMDcEc2060/qGKiQe+USwx xqY2Za43volBHzt/NIrlI9aHFRsz7r6pbM1D8gJbQe8x35Oo/G/P8aw+nt0j0dcR m4bVRF10RgIoi3y5DxLcGN9f5qkzGwF4zgNs14qlU84t42TG3+0ImjE632pdHnc/ FjXInOQ4ZEBbXNYOI4bo66zTO+zT813vSi+C+US1vzLIH+xB61NT0Az5Gn0IyZ17 V1+cAHPaZlsNyVeqBqXMpw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1747960646; x=1748047046; bh=c kvYx8LB+QYM7njWOYSsBZwube7gbqhZ6RvbHeDG/r4=; b=VR0HWtRjT1VUCfOkw cH6YrL5Kbukof1xmXUeRSExkC9xbPT3ori4Ogexg0/mpYAxFlItdEft90ms9g7P/ z5z2UNCUx86yoHJCrki2ezAkhNO/O0POoatX1OL7csNNrwUGDamJcU+noKBTOgy3 4uGdBBzDApbsLFpH2UyZj61Xh+UHlInqRpp4qD3I567hbnxBlaS0RAdSldIRbEYd G65NDKLLrj8KKW4+KJ8BmwdMrqIN1uYIYreVvnBx6hGPXWn9vRbhhvzaSc4C5CK7 Y6BVFfMB2wgjB/ow4BSNWJO0jqP1E+ZQ0coC8T4zqHlFJulSexOURLGB8PpxHkB/ hsuDg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdejgedvucdltddurdegfedvrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgf nhhsuhgsshgtrhhisggvpdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttd enucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvfhfh jggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmih htrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpedthfeuvddtveelgeeu leevvdejveehffevveehvdeuffdtfefhvdeugefgtefgtdenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggv vhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepug grnhgtohhlsegurghntgholhdrohhrghdprhgtphhtthhopeejkeehgeehseguvggssghu ghhsrdhgnhhurdhorhhgpdhrtghpthhtohepshhhihhpmhhinhhtshesghhmrghilhdrtg homhdprhgtphhtthhopeihihhkrghiseiiudhkrdguvghv X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 22 May 2025 20:37:24 -0400 (EDT) Message-ID: Date: Fri, 23 May 2025 03:37:21 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#78545: 31.0.50; project-mode-line is slow because it tries to read files on each update To: Daniel Colascione , 78545@debbugs.gnu.org, shipmints@gmail.com, yikai@z1k.dev References: <14B95357-B1E5-4301-AFF9-B5658EDE532E@dancol.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <14B95357-B1E5-4301-AFF9-B5658EDE532E@dancol.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78545 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 22/05/2025 18:53, Daniel Colascione wrote: > We could also just have the IO functions signal error if called during a mode line update. The first 'project-current' call might as well happen during the mode-line refresh, when the project root is not cached. What's problematic is having these calls do I/O every time.