GNU bug report logs -
#70036
30.0.50; Move file-truename to the C level
Previous Next
Full log
Message #218 received at 70036 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 19 Apr 2024 09:27:31 +0100
> Cc: theo <at> thornhill.no, felician.nemeth <at> gmail.com, 70036 <at> 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.
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.