From: "João Távora" <joaotavora@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: felician.nemeth@gmail.com, 70036@debbugs.gnu.org, theo@thornhill.no
Subject: bug#70036: a fix that
Date: Fri, 19 Apr 2024 13:00:54 +0100 [thread overview]
Message-ID: <CALDnm53Su0aBxQ2_7oJawdmBC=YTB7DejY9jGK_70MaxEorW5Q@mail.gmail.com> (raw)
In-Reply-To: <86r0f1bopx.fsf@gnu.org>
On Fri, Apr 19, 2024 at 12:01 PM Eli Zaretskii <eliz@gnu.org> wrote:
> No, IMO we should try it in both "emacs -Q" and in a session with a
> lot of buffers, to have the performance in its true relevant context.
> Most real-life Emacs sessions have many more buffers than we have in
> "emacs -Q". Worst-case testing is not always TRT, because it can skew
> the perspective and lead to wrong decisions.
The worst case here is relative. It's also a very plausible case
in the sense that starting Emacs, navigating to a file of a project
you're working on, and pressing M-x eglot is probably one of the most
common things you do with Eglot. So IOW the worst case is also the
common one.
> > > 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.
>
> We did that at least to some extent in the improvements submitted by
> Ihor and now available on master. From where I stand, we now have a
> reasonably performant implementation of find-buffer-visiting; I would
> need benchmarks showing otherwise to change my mind.
Theo's latest measurements show that -- in context -- there is a 4%
time spent in find-buffer-visiting and all of that is due to its
delegation of work to file-truename. Does that change your mind?
I reproduced the measurements but personally didn't feel this in any way
problematic (in my machine) to the use of Eglot. But Theo says there
are Java projects that run much, much worse and with much more friction,
but he can't share the data with us for other reasons. So it didn't
really change _my_ mind. For _me_ `f-b-v` was reasonably fast enough
when running Theo's recipe and definitely fast enough when trying
any other project.
But what changes my mind is the fact that:
* I believe Theo is telling the truth that it's a much bigger bottleneck
in Java projects.
* the workaround isn't _that_ ugly.
In summary, I still think f-b-v use in Eglot's publishDiagnostics handler is
cleanest conceptually, but because I believe Theo that it's a serious
bottleneck, I'm not opposed to skipping it with the alternative technique
already presented.
João
next prev parent reply other threads:[~2024-04-19 12:00 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 ` bug#70036: a fix that João Távora
2024-04-18 15:39 ` 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 [this message]
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='CALDnm53Su0aBxQ2_7oJawdmBC=YTB7DejY9jGK_70MaxEorW5Q@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.