GNU bug report logs -
#70036
30.0.50; Move file-truename to the C level
Previous Next
Full log
View this message in rfc822 format
> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 19 Apr 2024 13:54:23 +0100
> Cc: Theodor Thornhill <theo <at> thornhill.no>, felician.nemeth <at> gmail.com, 70036 <at> debbugs.gnu.org
>
> 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.
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.
This bug report was last modified 1 year and 104 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.