GNU bug report logs - #70036
30.0.50; Move file-truename to the C level

Previous Next

Full log

Message #263 received at 70036 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: felician.nemeth <at> gmail.com, 70036 <at> debbugs.gnu.org,
 Theodor Thornhill <theo <at> thornhill.no>
Subject: Re: bug#70036 a fix that
Date: Fri, 19 Apr 2024 13:54:23 +0100

On Fri, Apr 19, 2024 at 7:45 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> Thanks, but that is not what I asked to provide, for us to make a
> decision in this case.
> Could you please show benchmark times of the old code (before your
> changes), the code after your changes, and the current code in Git

I just noticed this and think a comment needs to be made about Eglot
and performance measurements specifically.

If a good `benchmark-run` or invocation can be made to measure a specific
problem, it is usually a very good tool.  But in Eglot, it's rare (*)

What some in this discussion may not understand is that Eglot works mostly
asynchronously.  The user invokes commands that ask something of the
server and that server will later respond with something that is hopefully
still relevant somehow.  On-the-fly diagnostics work like this, and even
startup can be asynchronous.  So any slowdowns are usually felt subjectively
in input lag across a session where the user is doing some work.

More often than not, there isn't a

  (benchamark-run 10 (eglot-foo <some-spoofed-arguiments>))

that can tell us something useful.  It's more like "I feel diagnostics take
longer to appear", "ElDoc spins my CPU fan", "completions feel laggy", and
things like that.

Of course, special Elisp code can be crafted to simulate how a user
interacts with Eglot, but that's not always easy due to the need to
mock complex objects (the server object, notably) and the aforementioned
async nature.

So that's why the best way to communicate these problems is via a profile
accompanied by the usual bullet-proof Emacs -Q recipe.  It should contain a
clear description of when profiler-start and profiler-stop are invoked, and
what the user did in between.   And that's _exactly_  what Theo did here,
and was useful to me: I reproduced his results perfectly.  Those profiles
easily tell us who the hotspots are at the Elisp level.

That's IF the hotspots are even at the Elisp level, because often a
slow-responding server is all it takes.  In those cases Eglot/Elisp may
or may not be "off the hook", depending on whether the cause for server
slowness is some earlier misconfiguration that is ultimately Eglot's
fault.

Maybe some of this info should be added to the Eglot manual in its
troubleshooting section.

João

(*) The eglot--glob section is a notable exception.  I used
benchmark-run to optimize back then.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.