[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#70036: a fix that
From: |
Eli Zaretskii |
Subject: |
bug#70036: a fix that |
Date: |
Fri, 19 Apr 2024 09:56:34 +0300 |
> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 18 Apr 2024 23:06:47 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, felician.nemeth@gmail.com,
> 70036@debbugs.gnu.org
>
> > > Still, for the very little data that there is available, I do take care
> > > to put in a much simpler fix that completely fixes the issue - as far as
> > > I or anyone reading the available data can see it.
> >
> > With this I disagree - but I guess I either have miscommunicated or have
> > provided unclear profiles or something inbetween.
>
> I scanned the bug thread twice and couldn't find any other profiles.
> There are mentions of textDocument/publishDiagnostics, but no actual
> profile data or information of how to see the performance problem.
>
> Maybe _I_ missed something. But I see you have now sent a perfect
> reproduction, so it doesn't matter.
There was no need to have any profiles to demonstrate that
file-truename is significantly slower than expand-file-name. It
should be clear just by looking at what file-truename does and how it
does that. Therefore, once I was told that resolving symlinks in
Emacs is unnecessary, replacing file-truename with expand-file-name
became a no-brainer, regardless of how many or how few percents of CPU
time it takes: it's just a waste of CPU cycles.
It's only now, that we decided symlinks _should_ be resolved by Emacs,
that quantitative performance of the code and the fraction of it due
to file-truename becomes relevant, and must be measured and compared
with alternatives.
> I still think the cleanest solution is to write file-truename
> in C.
I explained in that past discussion why this is not simple. So if
simpler solutions exist, we should prefer them.
> But if that can't be done, it doesn't seem terribly hard
> to get rid of find-buffer-visiting in publishDiagnostics and
> still remain symlink-correct.
find-buffer-visiting was made much faster lately, but that speedup
AFAIR shows up only if the session has a lot of buffers, so trying
these benchmarks in "emacs -Q" will not typically show the effect, and
could even obscure the file-truename effect as well, because the
number of calls to file-truename will be much smaller. But if calling
find-buffer-visiting from Eglot can be avoided, that is of course even
better.
> That's because every interesting result of find-buffer-visiting
> is a buffer for which we've already issued a 'didOpen', which
> in turn means we've already called file-truename once for it.
> If we cache that result (the basic idea behind the "better fix")
> it should be possible to find the buffer quicker just by iterating
> the list. That's what I will try to do, using your recipe as
> guide.
Thanks.
- bug#70036: a fix that, (continued)
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that,
Eli Zaretskii <=
- bug#70036: a fix that, Ihor Radchenko, 2024/04/19
- bug#70036: a fix that, Eli Zaretskii, 2024/04/19
- bug#70036: a fix that, Ihor Radchenko, 2024/04/30
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Eli Zaretskii, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19