From: "João Távora" <joaotavora@gmail.com>
To: Theodor Thornhill <theo@thornhill.no>,
Felician Nemeth <felician.nemeth@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, 70036@debbugs.gnu.org
Subject: bug#70036: a fix that
Date: Thu, 18 Apr 2024 16:32:33 +0100 [thread overview]
Message-ID: <CALDnm53enki1g6Gqpg1X3SziGC3dZ78RuXPEZAfU6Ze006Vq2A@mail.gmail.com> (raw)
In-Reply-To: <87le63xzjt.fsf@thornhill.no>
So I've read up on the bug report and I had a close look at the Eglot
usage profiles (not the micro-benchmarks, those are reasonably
irrelevant in what concerns Eglot). I see these kinds of things in
Theodor's profiles
18 8% - eglot--TextDocumentPositionParams
18 8% - eglot--TextDocumentIdentifier
18 8% - eglot--path-to-uri
15 7% - file-truename
14 6% - file-truename
14 6% - file-truename
11 5% - file-truename
11 5% - file-truename
11 5% - file-truename
10 4% - file-truename
10 4% - file-truename
8 3% - file-truename
8 3% - file-truename
8 3% - file-truename
5 2% - file-truename
3 1% - file-truename
2 0% - file-truename
1 0% file-truename
I could reproduce this, but never even close to the amount of ~7-8%.
Best I could get was 1% and I had to work pretty hard for it. If I
invoke completion or something heavier like that, it completely
dominates the profile.
25 1% - eglot--TextDocumentPositionParams
23 1% - eglot--TextDocumentIdentifier
23 1% - eglot-path-to-uri
13 0% - file-truename
13 0% - file-truename
13 0% - file-truename
13 0% file-truename
Maybe that's because file-truename is a recursive function that becomes
slower as the path it's asked to analyse becomes longer (obviously,
there can be a symlink at every junction).
So let's assume for the sake of argument that it's frequent for
users to have very long file names with very many components
or that the 1% overhead on the average path length is a real
performance problem for people.
If so, I think this simpler patch after my sig is all we need, as it
completely clears the profile of any "file-truename". I have reverted
the earlier patch and pushed a patch very similar to the one after my sig.
I'm interested in more details of exactly what constitutes actual
usage, i.e. what did you do while recording a cpu or mem profile.
As to the symlink-outside-the-project issue that Felicián raised,
I was not aware of that bug. It seems a separate bug at any rate.
I've also noticed that the Eglot automated tests are failing.
That too is unexpected. I will have a look at that, too.
João
commit 23d6517b2499089f775640b88958774ac2c91049
Author: João Távora <joaotavora@gmail.com>
Date: Thu Apr 18 08:03:10 2024 -0500
Better way to fix bug#70036
Cache eglot--cached-tdi per buffer, like we do with some many
other variables already, to avoid frequent expensive
recomputation of a value that requires potentially many
'file-truename' calls.
diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 806265544d6..6196aaff7a3 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -2517,12 +2517,17 @@ eglot-handle-request
(t (setq success :json-false)))
`(:success ,success)))
+(defvar-local eglot--cached-tdi nil
+ "A cached LSP TextDocumentIdentifier URI string.")
+
(defun eglot--TextDocumentIdentifier ()
"Compute TextDocumentIdentifier object for current buffer."
- `(:uri ,(eglot-path-to-uri (or buffer-file-name
- (ignore-errors
- (buffer-file-name
- (buffer-base-buffer)))))))
+ `(:uri ,(or eglot--cached-tdi
+ (setq eglot--cached-tdi
+ (eglot-path-to-uri (or buffer-file-name
+ (ignore-errors
+ (buffer-file-name
+ (buffer-base-buffer)))))))))
(defvar-local eglot--versioned-identifier 0)
--
João Távora
next prev parent reply other threads:[~2024-04-18 15:32 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 19:08 bug#70036: 30.0.50; Move file-truename to the C level Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27 19:44 ` Eli Zaretskii
2024-03-27 21:56 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 1:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 3:05 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 7:04 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 7:03 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 6:22 ` Eli Zaretskii
2024-03-28 7:03 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27 20:12 ` Felician Nemeth
2024-03-27 21:43 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 6:03 ` Eli Zaretskii
2024-03-28 7:10 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 8:52 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 11:55 ` Felician Nemeth
2024-03-28 12:08 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 9:46 ` Felician Nemeth
2024-03-30 11:18 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 12:45 ` Eli Zaretskii
2024-03-31 12:57 ` Felician Nemeth
2024-03-31 13:32 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 9:22 ` Ihor Radchenko
2024-03-28 10:59 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 11:18 ` Ihor Radchenko
2024-03-28 11:41 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 11:51 ` Ihor Radchenko
2024-03-28 12:47 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 13:52 ` Eli Zaretskii
2024-04-18 15:32 ` João Távora [this message]
2024-04-18 15:39 ` bug#70036: a fix that João Távora
2024-04-18 15:40 ` Ihor Radchenko
2024-04-18 15:45 ` João Távora
2024-04-18 15:49 ` Eli Zaretskii
2024-04-18 16:11 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-18 16:15 ` João Távora
2024-04-18 16:29 ` Eli Zaretskii
2024-04-18 17:22 ` João Távora
2024-04-18 17:53 ` Eli Zaretskii
2024-04-18 20:21 ` João Távora
[not found] ` <874jbycrd7.fsf@dick>
2024-04-18 21:26 ` João Távora
2024-04-18 21:37 ` João Távora
2024-04-19 9:17 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-18 21:32 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-18 22:06 ` João Távora
2024-04-18 23:59 ` João Távora
2024-04-19 6:09 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 6:26 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 8:06 ` João Távora
2024-04-19 9:05 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 8:01 ` João Távora
2024-04-19 9:10 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 9:22 ` João Távora
2024-04-19 5:58 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 7:52 ` João Távora
2024-04-19 9:14 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 6:56 ` Eli Zaretskii
2024-04-19 7:51 ` Ihor Radchenko
2024-04-19 10:51 ` Eli Zaretskii
2024-04-30 11:30 ` Ihor Radchenko
2024-05-02 9:40 ` Eli Zaretskii
2024-04-19 8:27 ` João Távora
2024-04-19 8:49 ` João Távora
2024-04-19 11:12 ` Eli Zaretskii
2024-04-19 11:34 ` João Távora
2024-04-19 18:13 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 18:59 ` João Távora
2024-04-19 19:42 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 11:01 ` Eli Zaretskii
2024-04-19 11:32 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 11:40 ` João Távora
2024-04-19 11:47 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 11:51 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 12:01 ` João Távora
2024-04-19 11:51 ` João Távora
2024-04-19 20:23 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 21:32 ` João Távora
2024-04-19 11:53 ` Eli Zaretskii
2024-04-19 11:59 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 12:03 ` João Távora
2024-04-19 12:00 ` João Távora
2024-04-19 12:13 ` Eli Zaretskii
2024-04-19 12:20 ` João Távora
2024-04-19 6:45 ` Eli Zaretskii
2024-04-19 7:38 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-19 12:54 ` João Távora
2024-04-19 14:32 ` Eli Zaretskii
2024-04-19 0:57 ` Yuan Fu
2024-04-19 1:20 ` João Távora
2024-04-22 22:11 ` Dmitry Gutov
2024-04-18 16:21 ` Eli Zaretskii
2024-04-18 16:12 ` João Távora
2024-04-18 16:24 ` Eli Zaretskii
2024-04-18 16:33 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-18 16:36 ` Eli Zaretskii
2024-04-18 17:26 ` João Távora
2024-04-18 17:27 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALDnm53enki1g6Gqpg1X3SziGC3dZ78RuXPEZAfU6Ze006Vq2A@mail.gmail.com \
--to=joaotavora@gmail.com \
--cc=70036@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=felician.nemeth@gmail.com \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.