From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ship Mints Newsgroups: gmane.emacs.bugs Subject: bug#73718: 31.0.50; Severe performance issue with Tramp and project-mode-line-format Date: Fri, 11 Oct 2024 10:35:06 -0400 Message-ID: References: <874j5lzhdn.fsf.ref@aol.com> <874j5lzhdn.fsf@aol.com> <29ebe27b-89d6-4861-8c5e-3db50a1660f3@yandex.ru> <86a5fdmg3h.fsf@mail.linkov.net> <71d57a53-f8d8-45f7-bff6-09f5acf292f8@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005aa5b406243465bf" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26484"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Ergus , Michael Albinus , 73718@debbugs.gnu.org, Juri Linkov To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 11 19:11:58 2024 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 1szJBG-0006i2-Gp for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 11 Oct 2024 19:11:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1szJ7N-0004mv-PB; Fri, 11 Oct 2024 13:07:58 -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 1szJ55-0000wP-13 for bug-gnu-emacs@gnu.org; Fri, 11 Oct 2024 13:05:38 -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 1szGl8-0007Su-0W for bug-gnu-emacs@gnu.org; Fri, 11 Oct 2024 10:36:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=5C77udv/yY3Katx3dtvMps1QhBX7CXgsngTR4NCe+qQ=; b=F+5lLzLTs2LYSgK2DJvMgMR7qq8BTobDVqBOWLPuZOo0Xw87gW2wL/crQMgcC4Mi9W7hfTV5s07mGgb1WwQkMcGLUS74e03Wk7uGku8gwOGMp+QQGVXKVX7EAvpk2eUN0yBLJdbj0xvPF6auk2X54aq1Btg0olWrZNU14WkBZam6uGZ2HfpXka15n/m3JL0jUiM4ZyRkoA7zgVmIzoC4pK5lmwiarptmscIRByROHKZln5H/X+8MMS8RPGAIXhF1bElBB+Hsa+OZMLi28elOIu9XtsoPaT7TSaRftKf1UxYXkIiEI6BZLExX6at9RSE+LyJdAD0rmqfSeewN4c1CFQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1szGlK-0006V2-JM for bug-gnu-emacs@gnu.org; Fri, 11 Oct 2024 10:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ship Mints Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Oct 2024 14:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73718 X-GNU-PR-Package: emacs Original-Received: via spool by 73718-submit@debbugs.gnu.org id=B73718.172865739824949 (code B ref 73718); Fri, 11 Oct 2024 14:37:02 +0000 Original-Received: (at 73718) by debbugs.gnu.org; 11 Oct 2024 14:36:38 +0000 Original-Received: from localhost ([127.0.0.1]:34944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1szGkw-0006UK-7v for submit@debbugs.gnu.org; Fri, 11 Oct 2024 10:36:38 -0400 Original-Received: from mail-vk1-f172.google.com ([209.85.221.172]:61598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1szGku-0006U7-3t for 73718@debbugs.gnu.org; Fri, 11 Oct 2024 10:36:36 -0400 Original-Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-50ca1581a1aso673374e0c.2 for <73718@debbugs.gnu.org>; Fri, 11 Oct 2024 07:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728657318; x=1729262118; 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=5C77udv/yY3Katx3dtvMps1QhBX7CXgsngTR4NCe+qQ=; b=Mf1sEIwpBLuB1Vd5AVyx1th1fIYJHcWlDyGQ13QGEUOGz0MB9JfRssYGonAp97EtIw kaYP2phXLSbRjag1j5dLXuZiq10PQ9da50iGffM2fgz39rGymZJQS2FvTUzemGUo74qI 3TqGGab9yMogcHzmIQpGYjX0h4M9BeAoP4X9qbHyPlmuINISWoag/vG4p+m3iAGSYkgc 2GIEkSI9jkLCMqh+K5veoPPV3H/AzRwc+aWc6hNDGHSsvJngZ0isZlLILb734i4a5MXE AwRTpD9FUgDhBW5j1hIu+M4fU5XJCCr+IppnbnAQepcrGJt12SRSRMfo4dGeJmtPLmO7 Z0GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728657318; x=1729262118; 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=5C77udv/yY3Katx3dtvMps1QhBX7CXgsngTR4NCe+qQ=; b=NXWze99qatgVWhzqBDLkPgz2JxCMm9NljcGD1MVZcTCh399P6Wj63HeoYNzbo6KgvE eeUBdT7WRFJ/E06+Ra8nsZGTsP1sBNo8ALY114xO9vi1Reb7QVnhLvoERedMczsZg0JZ 7buIIUu0nOF9XWtNfUNRGjDhS6lCl8GpJPqfB0OubtGVuXOiqWkI8mqvR3ZfDhDrVsJC /DE54ldqX0yR5rjOYeus+OzrQMfAIibwVkWSJQtlsYPrLlccjGf9zHUt1iFA3i7642sX k1OxYYL8oxInxBJeSFbn2h3sHuBOUnKmw7ObgqwW1V4Nix0I9EVpOoSNKml69rziBqpj jCtg== X-Forwarded-Encrypted: i=1; AJvYcCVUYgBw87blI321r9flTKGD03QTfPbmafKEf/ha3uj19Lh6vZf0DKddKfYotPWmNFqLb1Ve0g==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywvv+/DBG7i46EbnM7ev3Ut5prMU+p3GnGNZKkhjxsqzc5N1ifv wf8Bbwi36SgUBK5EVzlTzmCE+LzI0dpZQCZ1qZvCe62TgCAyxiHgGhPNW29i7cr8w0muPHVBoex ppiZbtLxHpxETLUsAVdj9Qd/uLjw= X-Google-Smtp-Source: AGHT+IFJtdSYbWCybv6wJLDUft6n4zZ9uoJIOxNeFGjigYVmkPwFTUUSdQ0n8QXnPtRbUZMq/70HYQ4lB0p4TDFikwY= X-Received: by 2002:a05:6122:2a51:b0:50a:b9c2:58cd with SMTP id 71dfb90a1353d-50d1f5c70ecmr1417506e0c.9.1728657317600; Fri, 11 Oct 2024 07:35:17 -0700 (PDT) In-Reply-To: <71d57a53-f8d8-45f7-bff6-09f5acf292f8@yandex.ru> 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:293365 Archived-At: --0000000000005aa5b406243465bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In addition to guarding project-try-vc, I also have a customized cache for non-projects specifically to get around the incessant retesting for what are effectively invariant conditions. If of any utility to others: (use-package project ... (defconst my:project--non-project-dir ".") ; nil disables the cache; NOTE: eglot relies on project-root so this has to be a real path (defun my/project-try-non-project-cache (dir) (unless (and my:project-vc-inhibit-remote (file-remote-p dir)) ; yet another optional remote guard (let ((proj (cons 'transient (or my:project--non-project-dir (expand-file-name dir))))) (vc-file-setprop dir 'project-vc proj) ; project caches via vc internal properties proj))) (add-to-list 'project-find-functions #'my/project-try-non-project-cache 'append)) ;; customized project current name function that respects ;; non-project marker and returns nil if a non-project (defun my/project-current-name (&optional buf) "Return the current project name for BUF, or nil if a non-project. If BUF is nil, the current buffer is used." (with-current-buffer (or buf (current-buffer)) (when-let* ((p (project-current)) (pn (project-name p))) (unless (string=3D pn my:project--non-project-dir) pn)))) ... ) On Thu, Oct 10, 2024 at 8:38=E2=80=AFPM Dmitry Gutov wro= te: > On 09/10/2024 19:10, Juri Linkov wrote: > > Or maybe better to cache the value of project-name on remove projects. > > Just the project->project-name mapping? Why not. I suppose there'd still > be a pause when switching projects, but it's not as bad. > > For general caching, from past threads it seems the most problematic > case is "no project". Because OT1H it's still costly it terms of remote > I/O. But on the other, this is exactly when the cache might get invalid > soon (because the user will initialize a Git repo, or create another > root marker, etc). > > I guess we should come back to this after bug#72300. > > > > --0000000000005aa5b406243465bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In addition to guarding=C2=A0project-try-vc, I also have a customized ca= che for non-projects specifically to get around the incessant retesting for= what are effectively invariant conditions.

If of any utility to others:

(use-package project
...
=C2=A0 (defconst my:p= roject--non-project-dir ".") ; nil disables the cache; NOTE: eglo= t relies on project-root so this has to be a real path
=C2=A0 (defun my/= project-try-non-project-cache (dir)
=C2=A0 =C2=A0 (unless (and my:projec= t-vc-inhibit-remote (file-remote-p dir)) ; yet another optional remote guar= d
=C2=A0 =C2=A0 =C2=A0 (let ((proj (cons 'transient (or my:project--= non-project-dir (expand-file-name dir)))))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (= vc-file-setprop dir 'project-vc proj) ; project caches via vc internal = properties
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proj)))
=C2=A0 (add-to-list &#= 39;project-find-functions #'my/project-try-non-project-cache 'appen= d))

=C2=A0 ;; customized project current name function that respects=
=C2=A0 ;= ; non-project marker and returns nil if a non-project
=C2=A0 (defun my/p= roject-current-name (&optional buf)
=C2=A0 =C2=A0 "Return the c= urrent project name for BUF, or nil if a non-project.
If BUF is nil, the= current buffer is used."
=C2=A0 =C2=A0 (with-current-buffer (or bu= f (current-buffer))
=C2=A0 =C2=A0 =C2=A0 (when-let* ((p (project-current= ))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (pn (p= roject-name p)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (unless (string=3D pn my:pr= oject--non-project-dir)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pn))))
...
)
On Thu, O= ct 10, 2024 at 8:38=E2=80=AFPM Dmitry Gutov <dgutov@yandex.ru> wrote:
On 09/10/2024 19:10, Juri Linkov wrote:
> Or maybe better to cache the value of project-name on remove projects.=

Just the project->project-name mapping? Why not. I suppose there'd s= till
be a pause when switching projects, but it's not as bad.

For general caching, from past threads it seems the most problematic
case is "no project". Because OT1H it's still costly it terms= of remote
I/O. But on the other, this is exactly when the cache might get invalid soon (because the user will initialize a Git repo, or create another
root marker, etc).

I guess we should come back to this after bug#72300.



--0000000000005aa5b406243465bf--