[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#70036: a fix that
From: |
Theodor Thornhill |
Subject: |
bug#70036: a fix that |
Date: |
Fri, 19 Apr 2024 13:32:42 +0200 |
Eli Zaretskii <eliz@gnu.org> writes:
>> 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.
>
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
- bug#70036: a fix that, (continued)
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Eli Zaretskii, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, Eli Zaretskii, 2024/04/19
- bug#70036: a fix that,
Theodor Thornhill <=
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Eli Zaretskii, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19