bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#66288: 29.1; Performance regression using pipe for subprocess


From: Dmitry Gutov
Subject: bug#66288: 29.1; Performance regression using pipe for subprocess
Date: Tue, 3 Oct 2023 23:22:26 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 03/10/2023 22:12, Chris Hanson wrote:
On 10/3/23 13:24, Eli Zaretskii wrote:
None of the above is needed anymore, as they don't seem to be
relevant.

The Lisp profiler seems to point to redisplay as the culprit:
redisplay_internal seems to take most of the time in these recipes.

Detailed examination of the Lisp profiler output shows that most of the redisplay  time is spent in fontification. I don't know if that helps.

I'd take a look at the profile specifically (it's not always easy to interpret).

Also, when you say fontification, does it include specific Lisp functions in the output? Ones that are defined in xscheme.el? (JFYI, you can press TAB on entries in the report to drill down the call three).

I think at this point, since none of the initial guesses seems to be
correct, running your recipe under perf and looking at the differences
would be our best bet?  That, and bisecting the Git repository.

This would still be useful.  I'm trying to see what has changed
between Emacs 28 and Emacs 29 in this regard that causes such a
massive slowdown, but bisecting and/or perf data could provide
valuable inputs to guide the search.

I've not used the perf-tools before. There seem to be quite a few of them, and it's not obvious to me what you want me to run. Any suggestions?

sudo perf record -p $(pidof emacs)
...
^C
sudo perf report





reply via email to

[Prev in Thread] Current Thread [Next in Thread]