bug#70036: a fix that

[João Távora]

On Fri, Apr 19, 2024 at 7:56 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > Maybe _I_ missed something.  But I see you have now sent a perfect
> > reproduction, so it doesn't matter.
>
> There was no need to have any profiles to demonstrate that
> file-truename is significantly slower than expand-file-name.

Of course.  And there wasn't any need for profiles OR benchmark
to understand that file-truename and expand-file-name do different
things, so comparing one to the other when that difference in behavior
is crucial for the caller is very similar to comparing apple and
oranges.

> It's only now, that we decided symlinks _should_ be resolved by Emacs,

I _think_, but can't be 100% sure, that I explicitly decided that 6 years
ago, I just didn't document it  explicitly beyond typing in "file-truename".
Git archeology brings me to a commit in 2018 where I was reorganizing
code, and file-truename was already there.  I definitely knew about
expand-file-name in 2018 though.

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

> > But if that can't be done, it doesn't seem terribly hard
> > to get rid of find-buffer-visiting in publishDiagnostics and
> > still remain symlink-correct.
>
> 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?  And that's what
Theo proposed.  And in the possible but not exactly super-common case
where  you have an extreme 15-long directory chain, find-buffer-visiting
was observed to weigh in at 4%, all because of its file-truename call.

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

João