bug#70036: a fix that

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 19 Apr 2024 09:27:31 +0100
> Cc: theo@thornhill.no, felician.nemeth@gmail.com, 70036@debbugs.gnu.org
> 
> > > 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.
> 
> Fair enough.  Shifting complexity around is what we do.  But
> having a performant file-truename is a strategically investment, it's
> a very common filesystem primitive that users expect to be as fast
> as it can be made.  Common Lisp has TRUENAME, Python has 'realpath()',
> etc.   We could compare (here benchmarks are definitely the best
> method)

file-truename does much more than just the equivalent of realpath.  If
all we needed was a single call to realpath, we'd done that in C long
ago.

The problem with rewriting file-truename in C is that we must be 110%
compatible to what the Lisp implementation does, since it's such a
low-level API that is used so widely.

> > 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.
> 
> I'm not sure what test you are suggesting.  If f-b-v performs _better_
> in "lots of buffers" situation, then we should measure Eglot's performance
> in the plausible _worse_ case of few buffers, no?

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.

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