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: Thu, 18 Apr 2024 23:06:47 +0100 Message-ID: References: <4e670617-6483-4159-a5cf-27a921764c38@email.android.com> 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="7357"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 70036@debbugs.gnu.org, felician.nemeth@gmail.com To: Theodor Thornhill Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 19 00:08: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 1rxZvQ-0001je-GF for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Apr 2024 00:08:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxZv4-0000Rv-HF; Thu, 18 Apr 2024 18:07:50 -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 1rxZv3-0000Rn-OT for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 18:07:49 -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 1rxZv3-0001RN-BH for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 18:07:49 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rxZvG-0001t3-Nq for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 18:08: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: Thu, 18 Apr 2024 22:08:02 +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.17134780436998 (code B ref 70036); Thu, 18 Apr 2024 22:08:02 +0000 Original-Received: (at 70036) by debbugs.gnu.org; 18 Apr 2024 22:07:23 +0000 Original-Received: from localhost ([127.0.0.1]:54962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxZub-0001of-Uh for submit@debbugs.gnu.org; Thu, 18 Apr 2024 18:07:22 -0400 Original-Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]:59597) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxZua-0001nn-5J for 70036@debbugs.gnu.org; Thu, 18 Apr 2024 18:07:21 -0400 Original-Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2d87660d5c9so14704131fa.2 for <70036@debbugs.gnu.org>; Thu, 18 Apr 2024 15:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713478020; x=1714082820; 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=cnDehmav1rOAZ70VpWy44L6AG18BzzAO0eNSpTci/QM=; b=AezBtUzcEDbSO3T4DRqqOolEh2i5xiGMz+GMn2MOJ7kjFeuK35lBbJC2/7DZ9wtEo8 2EBORALOydPSYIpUjexdwxCwmmU4gR7SneRiDCht6BulubtFLKxjQ/80Q2FgFH5dq5vY qNxXekTmE6DbJxnll4hBZl0lfjUjuIi7KoRmvCe8wDDU2VoyF8nT5wOUH+eQU7rLC2im LTWAo1ievD+htTENvfULlfhZiAELSiVZWDHAThyZzo0SJKKnNhDQBtjhG9bEK5aNUdK4 u6t28XHXMY4EbsjKtT5X9d6VNa+lJnnUaWLhuneIxCUiuTC8SJ733KIjNGzqD7Gm21ud PZKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713478020; x=1714082820; 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=cnDehmav1rOAZ70VpWy44L6AG18BzzAO0eNSpTci/QM=; b=j3mbHquE1iicsIf725GQjPW0LeMPTm2rkez16NWF9NjjD+e+yb3vFpg5CdvNhhSe7k EyoWaQUFaJdAENJgDfENH4mtCU7NllUi5D1QGRDW9Kr7V9M2QsPfdvFSuI6RaS7Fo7SE EiF0SfsQIgbD9Y7WEPnurLSy/JOvaUwjNe7ibmWhceb4e9Hm/KagOFoC7lwq6fTQBkVW T82kQpDFaghtZT+P1UTzhUi6+5qiMRrcyZMf25ZFR8BrcRf7w0gY7jAFRc1Wt880aiWP 6WJFKI+BkJVvZsVB0e8V3uY5zmYK19RlNEpZ6jUNy2ZPk6C1+Gqrz7QkYflWmxGDDJOi wRGQ== X-Forwarded-Encrypted: i=1; AJvYcCUiwcHN85TtO7Lj1i+9qRfnCHCUgdH9XEaYws+LIrLYFVtfupCIBAngGP8WesuMrFv48UrjllST0YbPfnCOduXz4o2RE0Y= X-Gm-Message-State: AOJu0Yx4KPUdd5JPvS/LtlNw7+Wt/J4VvAGvQNgcASrN00ZGtD7RpGD5 2CP8h6nNmRIxOhGon/RXkRrV9pvJEqVFBvN1MqSenK49Tleir5LPqmpl1/d2Eu+g05oz4EbpPVu TbvApy3g+lGZpNinqKnRAjg9rrN8= X-Google-Smtp-Source: AGHT+IGjjlSXcNqhQ/Slx5HfD8ItoBW5hdLJeNoKirjdKPjBTX8QW1YrFVdLXKcnFDiFyJl2XuS5fNj/ZIwNjnTc8vI= X-Received: by 2002:a2e:938d:0:b0:2d9:fa96:1620 with SMTP id g13-20020a2e938d000000b002d9fa961620mr160991ljh.29.1713478020011; Thu, 18 Apr 2024 15:07:00 -0700 (PDT) In-Reply-To: <4e670617-6483-4159-a5cf-27a921764c38@email.android.com> 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:283619 Archived-At: On Thu, Apr 18, 2024 at 10:32=E2=80=AFPM Theodor Thornhill wrote: > > Im having some email client issues. I hope this mail renders readable. > > It doesn't suggest anything other than it, nothing about > > textDocument/publishDiagnostics. There's 0 data about that > > and it never showed up in my profile. > > I don't remember exactly right now, but I believe I mentioned many times > the performance of file-truename directly, and find-buffer-visiting > which uses file-truename indirectly. Yes, but that's not the same as saying there's data about it. Your profiles don't show find-buffer-visiting as a hotspot. Or did I miss any? > Did I decline? I've lost track, but I believe I said something in the > lines of "let's discuss it first", but nevermind. Well, that's declining. Politely, but declining :) > > Still, for the very little data that there is available, I do take care > > to put in a much simpler fix that completely fixes the issue - as far a= s > > I or anyone reading the available data can see it. > > With this I disagree - but I guess I either have miscommunicated or have > provided unclear profiles or something inbetween. I scanned the bug thread twice and couldn't find any other profiles. There are mentions of textDocument/publishDiagnostics, but no actual profile data or information of how to see the performance problem. Maybe _I_ missed something. But I see you have now sent a perfect reproduction, so it doesn't matter. > > And nothing serious will happen after I reverted it, will there? > > Not serious, but now we have a performance regression ;-) As far as we can tell, *you* have one. Noone else has -- as far as I can tell from the 7 years that code has been there. So I wouldn't really call this a "regression", but that doesn't mean I won't try to solve it. I'm confident it can be done. Incidentally I work on deep repos *with* symlinks, so I'm personally interested in the solution too. > I'm fine. I do think you do come off strongly though, and it is not > always easy to judge if it is of good faith. Just think: what reason do I have to be in "bad faith"? I just invited you to collaborate in the GitHub repo and I want you to keep learning and improving Eglot. I just think you did a commit -- in perfectly good faith -- that clashes directly with what is a tenet of Eglot: correctness and backward compatibility. I also think there are other much better ways to fix the problem (the greatest of these ideas is yours!!! rewrite it is C). > And I don't think Eli moralizes on my behalf. I don't know why it's done and I don't care, but I think it helps noone. > 1. Install gopls > 2. Make some directory you can wipe out after the test and cd into it > 3. git clone git@github.com:theothornhill/gin.git foo/bar/baz/foo/bar/baz= /foo/bar/baz/foo/bar/baz/gin > 4. cd foo/bar/baz/foo/bar/baz/foo/bar/baz/foo/bar/baz/gin > 5. open fs.go in emacs and make sure some go mode is available. Go-ts-mod= e for example > 6. M-x profiler-start > 7. M-x eglot > 8. Wait 10-20 seconds. Do no actions other than let the lsp settle. > 9. M-x profiler-stop > 10. M-x profiler-report > 11. Rinse repeat with both or all variants of emacs with/without the > latest eglot changes. > I'll add my profiles, and let some metrics talk. This is from emacs -Q > from your "better fix" and the commit before your revert. Please try on > your systems and report back. Great recipe. > By the way. I have a hunch the reason this is so apparent now is because > of the faster json serde recently added to emacs. Not sure, but feels > like it. Json serde is almost gone from the profiles. What is Json serde? Is it Json SERialization/DEserialization? That commit by Hermann made it in? That's great!! So Eglot is probably faster overall. So I guess your bug report is about not missing a further optimization opportunity. Fine. Anyway is this the hotspot I should be trying to optimize? > 9 4% - find-buffer-visiting I still think the cleanest solution is to write file-truename in C. 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. That's because every interesting result of find-buffer-visiting is a buffer for which we've already issued a 'didOpen', which in turn means we've already called file-truename once for it. If we cache that result (the basic idea behind the "better fix") it should be possible to find the buffer quicker just by iterating the list. That's what I will try to do, using your recipe as guide. Jo=C3=A3o