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: kobarity <kobarity <at> gmail.com>
To: Tom Gillespie <tgbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 63622 <at> debbugs.gnu.org
Subject: bug#63622: lisp/progmodes/python.el: performance regression introduced by multiline font-lock
Date: Mon, 22 May 2023 00:44:03 +0900
[Message part 1 (text/plain, inline)]
I wrote:
> I agree.  It seems to me that it is not python-font-lock-extend-region
> itself that is slow, but rather font-lock's processing of the area
> extended by it.  So one workaround would be to limit the number of
> lines to be extended, as in the attached patch.  If this limit is
> exceeded, the area or the entire buffer must be font-locked manually
> later.  What do you think of this idea?

The cause of the slowdown seems to be in python-info-docstring-p.  So
another option would be to improve it.  Attached is a patch that
determines that if point is in parens except for "(", it is not a
docstring.  I can't think of a case where a docstring is in parens
except for "(".  However, usually more tests should be done.
[0001-Optimize-python-info-docstring-p.patch (application/octet-stream, attachment)]

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.