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

[Theodor Thornhill]

Ihor Radchenko <yantar92@posteo.net> writes:

> Theodor Thornhill <theo@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 :)