GNU bug report logs - #63622
lisp/progmodes/python.el: performance regression introduced by multiline font-lock

Previous Next

Package: emacs;

Reported by: Tom Gillespie <tgbugs <at> gmail.com>

Date: Sun, 21 May 2023 03:15:02 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Tom Gillespie <tgbugs <at> gmail.com>
Subject: bug#63622: closed (Re: bug#63622: lisp/progmodes/python.el:
 performance regression introduced by multiline font-lock)
Date: Fri, 26 May 2023 10:02:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#63622: lisp/progmodes/python.el: performance regression introduced by multiline font-lock

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 63622 <at> debbugs.gnu.org.

-- 
63622: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63622
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Eli Zaretskii <eliz <at> gnu.org>
To: kobarity <kobarity <at> gmail.com>
Cc: ruijie <at> netyu.xyz, tgbugs <at> gmail.com, 63622-done <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#63622: lisp/progmodes/python.el: performance regression
 introduced by multiline font-lock
Date: Fri, 26 May 2023 13:01:33 +0300
> Date: Thu, 25 May 2023 00:05:09 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
> 	Tom Gillespie <tgbugs <at> gmail.com>,
> 	Eli Zaretskii <eliz <at> gnu.org>,
> 	63622 <at> debbugs.gnu.org
> 
> Attached is a series of patches that replace the previous patches.

Thanks, installed on the emacs-29 branch, and closing the bug.

[Message part 3 (message/rfc822, inline)]
From: Tom Gillespie <tgbugs <at> gmail.com>
To: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Subject: lisp/progmodes/python.el: performance regression introduced by
 multiline font-lock
Date: Sat, 20 May 2023 20:14:19 -0700
The changes in 4915ca5dd4245a909c046e6691e8d4a1919890c8 have
introduced a significant performance regression when editing python
code that contains dictionary structures across multiple lines.

The current behavior makes Emacs unusable when editing python
dictionaries with more than 20 or so lines. I would suggest reverting
the commit until the performance issue can be addressed.

If I had to guess, this is probably being caused by a double
zero-or-more pattern (possibly implicit) in the new regexps that were
added/changed.

The literal dictionary below is sufficient to demonstrate the issue
and if you bisect and compare the behavior to the immediately prior
commit 31e32212670f5774a6dbc0debac8854fa01d8f92 the difference is
clear. Open the file and hit enter a couple of times and the lag is
obvious (if you can't detect the issue try doubling the number of
lines at the deepest nesting level from 25 to 50).

By profiling and varying the number of repeated lines (e.g. by
doubling them) it appears that the issue is some lurking quadratic
behavior in syntax-ppss as a result of the changes in 4914ca. In my
testing 25, 50, and 100 lines take 100ms, 800ms, and 5 seconds
respectively to insert a new line while the cursor is inside the outer
most paren.

Collapsing all the structures into one line hides the issue. The
longer each individual line the more rapid the slowdown.

The example below is not syntactically correct python, however it
highlights the issue in a way that is clearer than it would be
otherwise.

Examples that trigger the issue (repeat the 2nd line 50 or 100 times
to see the effect). Any combination of paren types will cause the
issue.  The closing paren does not have to be present and does not
prevent the issue.

#+begin_src python
[''
'' []
#+end_src
#+begin_src python
[''
[] ''
#+end_src
#+begin_src python
[''
'' {}
#+end_src
#+begin_src python
{''
'' ()
#+end_src
#+begin_src python
[""
'' []
#+end_src

Examples that are do not cause the issue.
#+begin_src python
[a
'' []
#+end_src
#+begin_src python
[''
'' a
#+end_src
#+begin_src python
[''
'' ''
#+end_src
#+begin_src python
[[]
[] []
#+end_src
#+begin_src python
[[]
[] ''
#+end_src

Example of syntactically correct python that causes the issue.
#+begin_src python
{'':
 {
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
  '': {'': ''},
 },
 '': ['']}
#+end_src



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

Previous Next


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