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: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 70036 <at> debbugs.gnu.org
Subject: bug#70036: 30.0.50; Move file-truename to the C level
Date: Thu, 28 Mar 2024 13:47:27 +0100

Ihor Radchenko <yantar92 <at> posteo.net> writes:

> Theodor Thornhill <theo <at> thornhill.no> writes:
>
>> I'm sorry, but I don't see the real difference here. Yes, the profile is
>> more detailed this way, but it doesn't change the fact that
>> file-truename is slow, does it?
>
> It does not, but it is important for your suggestion to move
> `file-truename' to the C level.
>
> If the slow parts of `file-truename' are the calls to C subroutines,
> rewriting `file-truename' in C will not help much with the performance.
> (Unless you try hard and move parts of the used subroutines into the C
> implementation of `file-truename', but that will involve copy-pasting
> parts of the existing code and cannot be a good idea without very strong
> justification)
>

Yeah, I agree with this.

>> The question to me is whether or not this is an acceptable performance
>> hit to take for eglot given what it's trying to do, and my opinion is
>> no. Whether or not it should be moved to C is open to suggestion. I'm
>> preparing a patch that only targets Eglot by removing reliance on this
>> function.
>
> If your aim is improving eglot performance specifically, sure.
> If your aim is improving `file-truename' performance in general, a more
> detailed analysis can be helpful.
>

And this.

Wrt eglot specifically or not - I'm not sure whether or not this affects
other parts of emacs. My guess is that it will, but I haven't
investigated that yet.

>>        17839  63% - command-execute
>>        17794  63%  - funcall-interactively
>>        17793  63%   - eval-last-sexp
>>        17793  63%    - #<compiled-function EF0>
>>        17793  63%     - elisp--eval-last-sexp
>>        17791  63%      - eval
>>        17791  63%       - benchmark-call
>>        17788  63%        - #<lambda 219>
>>        17783  63%         - file-truename
>>        17576  62%          - let
>> ...
>
> When you have recursive calls, it is generally more useful to view
> reversed calltree (B) in the profiler report. It will accumulate calls
> to the same function together, regardless on how deep in the call stack
> these calls are made.
>

TIL - thanks :)

Previous Next

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