GNU bug report logs -
#51006
28.0.60; Slowness while navigating in inferior-python-mode
Previous Next
Reported by: Simen Heggestøyl <simenheg <at> runbox.com>
Date: Mon, 4 Oct 2021 12:55:01 UTC
Severity: normal
Found in version 28.0.60
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51006 in the body.
You can then email your comments to 51006 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#51006; Package
emacs.
(Mon, 04 Oct 2021 12:55:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Simen Heggestøyl <simenheg <at> runbox.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 04 Oct 2021 12:55:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The following recipe makes Emacs freeze, starting from 'emacs -Q':
1. Type 'M-x run-python RET'.
2. In the inferior-python-mode buffer that pops up, insert the following:
{
"foo-1": "bar-1",
"foo-2": "bar-2",
"foo-3": "bar-3",
"foo-4": "bar-4",
"foo-5": "bar-5",
"foo-6": "bar-6",
"foo-7": "bar-7",
"foo-8": "bar-8",
"foo-9": "bar-9",
}
3. Navigate up and down inside this structure by running 'next-line' and
'previous-line' in quick succession, alternating between them.
4. The movement appears slower and slower, eventually freezing up Emacs.
I've observed this in Emacs 27.2 as well, so it doesn't seem new to
Emacs 28.
Here's the report from a quick profiling I did in Emacs 28:
13447 94% - python-shell-font-lock-post-command-hook
13444 94% - font-lock-ensure
13444 94% - #<compiled -0x19f3968dc99b6307>
13444 94% - font-lock-fontify-region
13444 94% - font-lock-default-fontify-region
13420 94% - font-lock-fontify-syntactically-region
13420 94% - python-font-lock-syntactic-face-function
13412 94% - python-info-docstring-p
13396 94% + python-nav-beginning-of-statement
4 0% + python-info-assignment-statement-p
8 0% + font-lock-fontify-keywords-region
3 0% + font-lock-mode
529 3% + ...
183 1% + command-execute
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#51006; Package
emacs.
(Mon, 04 Oct 2021 13:25:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 51006 <at> debbugs.gnu.org (full text, mbox):
> From: Simen Heggestøyl <simenheg <at> runbox.com>
> Date: Mon, 04 Oct 2021 14:54:24 +0200
>
> Here's the report from a quick profiling I did in Emacs 28:
>
> 13447 94% - python-shell-font-lock-post-command-hook
> 13444 94% - font-lock-ensure
> 13444 94% - #<compiled -0x19f3968dc99b6307>
> 13444 94% - font-lock-fontify-region
> 13444 94% - font-lock-default-fontify-region
> 13420 94% - font-lock-fontify-syntactically-region
> 13420 94% - python-font-lock-syntactic-face-function
> 13412 94% - python-info-docstring-p
> 13396 94% + python-nav-beginning-of-statement
> 4 0% + python-info-assignment-statement-p
> 8 0% + font-lock-fontify-keywords-region
> 3 0% + font-lock-mode
> 529 3% + ...
> 183 1% + command-execute
Please repeat the profiling experiment, but after loading python.el
(NOT python.elc). This should produce a more detailed profile that
would pinpoint the culprit more accurately. Based on skimming the
source code, my first suspect is syntax-ppss, but that could be a bad
guess.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#51006; Package
emacs.
(Mon, 04 Oct 2021 19:23:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 51006 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Please repeat the profiling experiment, but after loading python.el
> (NOT python.elc). This should produce a more detailed profile that
> would pinpoint the culprit more accurately. Based on skimming the
> source code, my first suspect is syntax-ppss, but that could be a bad
> guess.
Hi Eli, thanks for the quick response.
I repeated the experiment after deleting python.elc to avoid loading it
on startup (maybe there's a simpler way of preventing that?). The new
profiler report is attached.
Another detail: This doesn't happen in the ordinary python-mode, only in
inferior-python-mode.
[CPU-Profiler-Report-2021-10-04-21-13-53.txt (text/plain, inline)]
47639 95% - python-shell-font-lock-post-command-hook
47639 95% - let
47639 95% - if
47639 95% - progn
47635 95% - let*
47627 95% - let
47623 95% - save-current-buffer
47623 95% - save-current-buffer
47615 95% - let
47611 95% - if
47611 95% - funcall
47611 95% - font-lock-ensure
47611 95% - #<compiled -0x15f49b30cf8ae947>
47611 95% - font-lock-fontify-region
47611 95% - font-lock-default-fontify-region
47400 94% - font-lock-fontify-syntactically-region
47400 94% - python-font-lock-syntactic-face-function
47400 94% - if
47400 94% - if
47399 94% - python-info-docstring-p
47387 94% - save-excursion
47096 94% - python-nav-beginning-of-statement
47072 94% - let*
44158 88% - cond
44151 88% - python-nav-beginning-of-statement
44127 88% - let*
41183 82% - cond
41175 82% - python-nav-beginning-of-statement
41133 82% - let*
38429 76% - cond
38421 76% - python-nav-beginning-of-statement
38409 76% - let*
35842 71% - cond
35838 71% - python-nav-beginning-of-statement
35806 71% - let*
33257 66% - cond
33177 66% - python-nav-beginning-of-statement
32662 65% - let*
32414 64% syntax-ppss
124 0% cond
20 0% or
76 0% - save-excursion
68 0% - python-info-line-ends-backslash-p
64 0% - save-excursion
56 0% - while
56 0% - and
56 0% - nth
56 0% - or
52 0% syntax-ppss
2525 5% - syntax-ppss
12 0% #<compiled 0xb89c315bc3a37ea>
20 0% - or
8 0% nth
8 0% - let
4 0% and
2551 5% syntax-ppss
4 0% - or
4 0% nth
2672 5% - syntax-ppss
4 0% #<compiled 0xb89c315bc3a37ea>
4 0% or
4 0% - save-excursion
4 0% - python-info-line-ends-backslash-p
4 0% - save-excursion
4 0% - while
4 0% - and
4 0% - nth
4 0% - or
4 0% syntax-ppss
2916 5% - syntax-ppss
4 0% #<compiled 0xb89c315bc3a37ea>
8 0% - or
4 0% nth
2886 5% syntax-ppss
4 0% - or
4 0% nth
271 0% - let
217 0% - if
213 0% - and
173 0% - not
169 0% - python-info-assignment-statement-p
165 0% - save-excursion
165 0% - let
137 0% - if
133 0% - python-nav-beginning-of-statement
113 0% - let*
77 0% - cond
65 0% - save-excursion
61 0% - python-info-line-ends-backslash-p
48 0% - save-excursion
36 0% - while
32 0% - and
28 0% - nth
28 0% - or
28 0% syntax-ppss
8 0% - if
4 0% equal
24 0% syntax-ppss
8 0% or
20 0% - while
20 0% - and
8 0% re-search-forward
24 0% looking-at-p
4 0% concat
8 0% if
84 0% - font-lock-fontify-keywords-region
84 0% - #<lambda -0xaef49294dba7a2c>
84 0% - let
4 0% - if
4 0% - or
4 0% - nth
4 0% - or
4 0% syntax-ppss
8 0% - if
8 0% - progn
8 0% - font-lock-mode
8 0% - font-lock-default-function
8 0% - font-lock-mode-internal
8 0% - font-lock-unfontify-buffer
8 0% - font-lock-default-unfontify-buffer
8 0% font-lock-unfontify-region
4 0% python-shell-get-process-or-error
8 0% - while
8 0% - let*
4 0% or
4 0% set-text-properties
2364 4% + ...
47 0% + command-execute
3 0% + redisplay_internal (C function)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#51006; Package
emacs.
(Mon, 04 Oct 2021 19:54:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 51006 <at> debbugs.gnu.org (full text, mbox):
> From: Simen Heggestøyl <simenheg <at> runbox.com>
> Cc: 51006 <at> debbugs.gnu.org
> Date: Mon, 04 Oct 2021 21:21:56 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Please repeat the profiling experiment, but after loading python.el
> > (NOT python.elc). This should produce a more detailed profile that
> > would pinpoint the culprit more accurately. Based on skimming the
> > source code, my first suspect is syntax-ppss, but that could be a bad
> > guess.
>
> Hi Eli, thanks for the quick response.
>
> I repeated the experiment after deleting python.elc to avoid loading it
> on startup (maybe there's a simpler way of preventing that?). The new
> profiler report is attached.
>
> Another detail: This doesn't happen in the ordinary python-mode, only in
> inferior-python-mode.
Thanks. So yes, it's syntax-ppss. Time to bring Stefan (CC'ed) on
board of this discussion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#51006; Package
emacs.
(Fri, 22 Jul 2022 09:42:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 51006 <at> debbugs.gnu.org (full text, mbox):
This seems to have been fixed on master by:
commit ab34293d849086a67effc52800e18bab1400ce72
Author: Lars Ingebrigtsen <larsi <at> gnus.org>
Date: Wed Oct 13 18:44:35 2021 +0200
Fix problem with multiline fontification in interactive Python
* lisp/progmodes/python.el
(python-shell-font-lock-post-command-hook): When doing multi-line
(`C-c SPC') inputs, remove all the preceding lines when doing
fontification (bug#47657).
Should it be backported to emacs-28 as the problem still exists there?
Otherwise I think this bug can be closed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#51006; Package
emacs.
(Fri, 22 Jul 2022 11:23:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 51006 <at> debbugs.gnu.org (full text, mbox):
> From: Simen Heggestøyl <simenheg <at> runbox.com>
> Cc: 51006 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 22 Jul 2022 11:41:13 +0200
>
> This seems to have been fixed on master by:
>
> commit ab34293d849086a67effc52800e18bab1400ce72
> Author: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed Oct 13 18:44:35 2021 +0200
>
> Fix problem with multiline fontification in interactive Python
>
> * lisp/progmodes/python.el
> (python-shell-font-lock-post-command-hook): When doing multi-line
> (`C-c SPC') inputs, remove all the preceding lines when doing
> fontification (bug#47657).
>
> Should it be backported to emacs-28 as the problem still exists there?
Fine by me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#51006; Package
emacs.
(Fri, 22 Jul 2022 20:08:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 51006 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Should it be backported to emacs-28 as the problem still exists there?
>
> Fine by me.
If I remember correctly, it's not a regression, but a long-standing bug,
so I don't think backporting is warranted here.
Simen Heggestøyl <simenheg <at> runbox.com> writes:
> Otherwise I think this bug can be closed.
OK; done.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
51006 <at> debbugs.gnu.org and Simen Heggestøyl <simenheg <at> runbox.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 22 Jul 2022 20:08:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 20 Aug 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 248 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.