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
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 12:41:08 +0100
Ihor Radchenko <yantar92 <at> posteo.net> writes:
> Theodor Thornhill <theo <at> thornhill.no> writes:
>
>> Not sure I understand what you mean. I tried it again, but this time the
>> call is 100000 times and in an existing file on my system which is
>> deeply nested. I run emacs with `emacs -Q` from a build on
>> `30b1b0d7cd8e4d46a601e9737350cda970f6bab0`.
>>
>> the relevant part from the profile this time:
>> ```
>> 15478 72% - command-execute
>> 15440 72% - funcall-interactively
>> 15439 72% - eval-last-sexp
>> 15439 72% - #<compiled-function 0C4>
>> 15439 72% - elisp--eval-last-sexp
>> 15436 71% - eval
>> 15436 71% - benchmark-call
>> 15434 71% - #<lambda E8B>
>> 15434 71% - file-truename
>> 13536 63% - file-truename
>> 12224 57% - file-truename
>> ...
>> To me this looks like it spends a lot of time in recursive calls
>
> No. It is just that your `file-truename' is native-compiled and the
> profiler is unable to get the details from inside native subr code.
>
> You can re-evaluate the defun to reveal the details in the profiler
> output. Or use Emacs compiled without native-compilation support.
>
> --
> 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>
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?
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.
Theo
```
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
17546 62% - while
17529 62% - let
17358 61% - if
17356 61% - let
16365 58% - or
15969 56% - if
15964 56% - let
15951 56% - file-name-as-directory
15824 56% - file-truename
15788 56% - let
15768 56% - while
15712 55% - let
15579 55% - if
15577 55% - let
7224 25% - or
3429 12% - if
3325 11% - let
3059 10% - file-name-as-directory
1866 6% - file-truename
1501 5% - let
1276 4% - while
1121 3% - let
1004 3% find-file-name-handler
18 0% if
49 0% - setcar
26 0% 1-
37 0% - if
23 0% <
36 0% not
97 0% - if
46 0% - eq
8 0% quote
7 0% or
218 0% - cond
112 0% - and
95 0% - string=
73 0% substring
82 0% - or
57 0% string=
17 0% or
123 0% - setcar
83 0% - cons
```
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.