Subject: Re: bug#70036: 30.0.50; Move file-truename to the C level

From: Theodor Thornhill <[email-masked]>
Date: Thu, 28 Mar 2024 08:10:28 +0100

Eli Zaretskii <[email-masked]> writes:

>> Cc: [email-masked]
>> Date: Wed, 27 Mar 2024 22:43:25 +0100
>> From:  Theodor Thornhill via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <[email-masked]>
>> 
>> Felician Nemeth <[email-masked]> writes:
>> 
>> >> I've been studying Eglots performance and have been noticing a couple
>> >> of things that I find very interesting. It seems like `file-truename`
>> >> is in the hot path
>> >
>> > I think Eglot repeatedly calls file-truename with the same argument (or
>> > with an argument from a small set of filenames.)
>> 
>> This is true, to some extent.
>
> Can someone explain why Eglot needs to call file-truename in the first
> place?

I tried quickly just replacing file-truename with expand-file-name, and
from some quick testing, it seems to work, and of course remove
file-truenames slow performance in the profiles:

```
@@ -1085,7 +1089,7 @@ eglot-uri-to-path
 
 (defun eglot-path-to-uri (path)
   "Convert PATH, a file name, to LSP URI string and return it."
-  (let ((truepath (file-truename path)))
+  (let ((truepath (expand-file-name path)))
     (if (and (url-type (url-generic-parse-url path))
              ;; It might be MS Windows path which includes a drive
              ;; letter that looks like a URL scheme (bug#59338)
```

This wouldn't help for the usage in find-buffer-visiting, though. But
this one could more easily be replaced by reworking the diagnostics
handler. We could store the last received diagnostics in the server
object, and do a quick lookup from known buffers there.

Theo