From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#70036: a fix that Date: Fri, 19 Apr 2024 09:27:31 +0100 Message-ID: References: <4e670617-6483-4159-a5cf-27a921764c38@email.android.com> <864jbxden1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36769"; mail-complaints-to="usenet@ciao.gmane.io" Cc: felician.nemeth@gmail.com, 70036@debbugs.gnu.org, theo@thornhill.no To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 19 10:29:13 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 1rxjcO-0009OE-TJ for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Apr 2024 10:29:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxjc1-0008Bb-Tn; Fri, 19 Apr 2024 04:28:49 -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 1rxjc0-0008BO-BA for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 04:28:48 -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 1rxjc0-0003Bn-2I for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 04:28:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rxjcE-0007eV-0a for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 04:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Apr 2024 08:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70036 X-GNU-PR-Package: emacs Original-Received: via spool by 70036-submit@debbugs.gnu.org id=B70036.171351529029083 (code B ref 70036); Fri, 19 Apr 2024 08:29:01 +0000 Original-Received: (at 70036) by debbugs.gnu.org; 19 Apr 2024 08:28:10 +0000 Original-Received: from localhost ([127.0.0.1]:57697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxjbM-0007Ya-CY for submit@debbugs.gnu.org; Fri, 19 Apr 2024 04:28:09 -0400 Original-Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:53468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxjbI-0007X5-4C for 70036@debbugs.gnu.org; Fri, 19 Apr 2024 04:28:06 -0400 Original-Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2db2f6cb312so32455361fa.2 for <70036@debbugs.gnu.org>; Fri, 19 Apr 2024 01:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713515264; x=1714120064; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YINAPaYsBLlfJAgAO40o/47EmTZ6oVxA8eB/eelJt+s=; b=A+mLPz0G7ju890ExwRh6EEaAMtzcfZYzFo6Z6hHVBAgQ7xUrFuRRECotykF8hGF26p 9znbPxxwnD+wDx1wS7iDzvxSxPR0KDsp1LuimnPSJNwcwnEJVllk+2BYQGEW6CmU1/aQ AwLVs4oRMdrtkbbGjfNn3Ya7KqUtgc2HF8hYiCmb392KZec5joAoIwi8DEDyv9esTi5a PxyRWeOFDkmjIghYtTDu7lDYmmcsTYftuE7zartpBSQS9aTwKarG7jL9p4Czsl71kJTD Q3vWydIaR5bbFj0XTx0Q/IQT5ScVNAiDc45eyxIE22wvv+Y7YqQnzsBjUPD8T7Wzonc9 948g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713515264; x=1714120064; h=content-transfer-encoding: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=YINAPaYsBLlfJAgAO40o/47EmTZ6oVxA8eB/eelJt+s=; b=GpnNCJzqkOTN2BfvKDohJGVdGG4GcherYAeIXWOSxSTneTbMeWb0i20jqI52hnUio8 edvrXyZAeVzzDz28rN7tVdxnWdQzDy795KsmOWoHe0OTlB3SrgoiMa6Kte3TNDKuQeMA E3AwLi2BBTf8/zVPeRwOgYhth1VsTahGI08DnVon7bh2FcbmHFSuf41egHiIYqsWRVsy nYgPJK9GKekeZVIxPKGyWRDelA9eROhM3zBozvw3tBMEPgvIi6wBB1/WTCR0p5OKIb4T XQUEYdwNJ4Xeo67V+y2GyhPUdxVnRpokyG3Dz19iqt9eiOlcLgAAcMldQsgGOLC6oJ6R 0rsg== X-Forwarded-Encrypted: i=1; AJvYcCX3m54idRqgTiyet79qnVgwLdyx+s2em2V8La7omJ1hJofSW1/lP/I2Q6DGGfYVexg8g7H3WOjsmyVTnhPPwq2kmOYQZP0= X-Gm-Message-State: AOJu0YwjyY+M5GfoAqBLgBDOplkz7lOuoLYaPI72xz18LptZVd8vM5hh 3sTKUHsb+Ule3Nz3RAugO7PfDw1xWhQHA4vKvqMKtX+74+qY0UCtQn7SAQTTB+IRJFrleH4HHk6 buezA+mWK847SpKn3khpUvplppg0= X-Google-Smtp-Source: AGHT+IFZaoxMKLHTGbnrSnJKktqXGMfilghP77jHARgv5lZuY1fnLvjV+iAOhCbUM9fIRuMD9Ui3Xoziy4C3+zHcLz4= X-Received: by 2002:a2e:aa13:0:b0:2d8:bda5:c5f5 with SMTP id bf19-20020a2eaa13000000b002d8bda5c5f5mr1051450ljb.35.1713515263773; Fri, 19 Apr 2024 01:27:43 -0700 (PDT) In-Reply-To: <864jbxden1.fsf@gnu.org> 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:283651 Archived-At: On Fri, Apr 19, 2024 at 7:56=E2=80=AFAM Eli Zaretskii wrote: > > Maybe _I_ missed something. But I see you have now sent a perfect > > reproduction, so it doesn't matter. > > There was no need to have any profiles to demonstrate that > file-truename is significantly slower than expand-file-name. Of course. And there wasn't any need for profiles OR benchmark to understand that file-truename and expand-file-name do different things, so comparing one to the other when that difference in behavior is crucial for the caller is very similar to comparing apple and oranges. > It's only now, that we decided symlinks _should_ be resolved by Emacs, I _think_, but can't be 100% sure, that I explicitly decided that 6 years ago, I just didn't document it explicitly beyond typing in "file-truename"= . Git archeology brings me to a commit in 2018 where I was reorganizing code, and file-truename was already there. I definitely knew about expand-file-name in 2018 though. > > I still think the cleanest solution is to write file-truename > > in C. > > I explained in that past discussion why this is not simple. So if > simpler solutions exist, we should prefer them. Fair enough. Shifting complexity around is what we do. But having a performant file-truename is a strategically investment, it's a very common filesystem primitive that users expect to be as fast as it can be made. Common Lisp has TRUENAME, Python has 'realpath()', etc. We could compare (here benchmarks are definitely the best method) > > But if that can't be done, it doesn't seem terribly hard > > to get rid of find-buffer-visiting in publishDiagnostics and > > still remain symlink-correct. > > find-buffer-visiting was made much faster lately, but that speedup > AFAIR shows up only if the session has a lot of buffers, so trying > these benchmarks in "emacs -Q" will not typically show the effect, and > could even obscure the file-truename effect as well, because the > number of calls to file-truename will be much smaller. I'm not sure what test you are suggesting. If f-b-v performs _better_ in "lots of buffers" situation, then we should measure Eglot's performance in the plausible _worse_ case of few buffers, no? And that's what Theo proposed. And in the possible but not exactly super-common case where you have an extreme 15-long directory chain, find-buffer-visiting was observed to weigh in at 4%, all because of its file-truename call. > But if calling > find-buffer-visiting from Eglot can be avoided, that is of course even > better. Yes, that's what my latest patch does. But ideally it would be cleaner (IMHO) to have a fast usable find-buffer-visiting by speeding up its underlying file-truename. Jo=C3=A3o