bug#70036: a fix that

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 19 Apr 2024 13:54:23 +0100
> Cc: Theodor Thornhill <theo@thornhill.no>, felician.nemeth@gmail.com, 70036@debbugs.gnu.org
> 
> On Fri, Apr 19, 2024 at 7:45 AM Eli Zaretskii <eliz@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.

benchamark-run can be unusable in this case, but primitives that
measure time are still useful, even if one needs to insert some
special calls into the code that measure time.

> 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.

The profiler is not very useful in such cases because it doesn't
provide a clear picture of the time it took some code to execute.
Also because typically there's a large portion of it that points to
irrelevant functions line execute-extended-command etc.