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>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: felician.nemeth <at> gmail.com, 70036 <at> debbugs.gnu.org, theo <at> thornhill.no
Subject: bug#70036: a fix that
Date: Fri, 19 Apr 2024 13:00:54 +0100

On Fri, Apr 19, 2024 at 12:01 PM Eli Zaretskii <eliz <at> 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

Previous Next

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