GNU bug report logs - #66288
29.1; Performance regression using pipe for subprocess

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Chris Hanson <cph <at> chris-hanson.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 66288 <at> debbugs.gnu.org
Subject: bug#66288: 29.1; Performance regression using pipe for subprocess
Date: Tue, 3 Oct 2023 23:22:26 +0300

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

Previous Next

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