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

[kobarity]

Tom Gillespie wrote:
> The changes in 4915ca5dd4245a909c046e6691e8d4a1919890c8 have
> introduced a significant performance regression when editing python
> code that contains dictionary structures across multiple lines.

Hi Tom and Eli,

Thanks for bringing this issue to my attention.

> As far as I can tell the existing implementation for python font locking
> has some quadratic behavior that is revealed when a region is extended
> inside a nested dictionary with multiple lines.

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?

Even if we adopt this idea, there remain several points to consider:

- How many lines are appropriate for the limit?
- Is it better to make the limit customizable?
- python-ts-mode should be excluded for this limit?

0001-Workaround-performance-degradation-when-editing-mult.patch
Description: Binary data