GNU bug report logs - #70036
30.0.50; Move file-truename to the C level

Previous Next

Package: emacs;

Reported by: Theodor Thornhill <theo <at> thornhill.no>

Date: Wed, 27 Mar 2024 19:10:02 UTC

Severity: normal

Found in version 30.0.50

Full log


Message #59 received at 70036 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 70036 <at> debbugs.gnu.org
Subject: Re: bug#70036: 30.0.50; Move file-truename to the C level
Date: Thu, 28 Mar 2024 11:51:06 +0000
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)

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

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

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>




This bug report was last modified 1 year and 104 days ago.

Previous Next


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