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: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>, João Távora <joaotavora <at> gmail.com>
Cc: 70036 <at> debbugs.gnu.org, felician.nemeth <at> gmail.com
Subject: bug#70036: a fix that
Date: Fri, 19 Apr 2024 13:32:42 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

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

I wonder - why can't we use just buffer-file-truename?

In the below function, wouldn't buffer-file-truename let us avoid the
file-truename in eglot-path-to-uri?


(defun eglot--TextDocumentIdentifier ()
  "Compute TextDocumentIdentifier object for current buffer."
  `(:uri ,(or eglot--cached-tdi
              (setq eglot--cached-tdi
                    (eglot-path-to-uri (or buffer-file-name
                                           (ignore-errors
                                             (buffer-file-name
                                              (buffer-base-buffer)))))))))


> 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

Previous Next

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