bug#15295: python mode slow to unusable

["Andreas Röhler" <andreas.roehler@easy-emacs.de>]

Am 27.10.2013 05:23, schrieb Stefan Monnier:
> Could you take a look at this, as well?
>
>
>          Stefan
>
>>>>>> "Michael" == Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Alex V. Koval <alex@ua2web.com> writes:
>>> For me this is happen as well. Emacs, starting from version 24.3 became
>>> so slow in Python mode that I had to tell all developers at our company
>>> to use version 24.2 until I sorted this out.
>>>
>>> Sit today and started trying various emacs versions, and calling
>>> different functions. The suggested test case from original author above,
>>> runs with this benchmark:
>>>
>>> (7.3956507 53 1.8788885930000063)
>
>> I profiled a bit, and, at least in this example, these two functions
>> seem to be extremely inefficient in combination:
>
>> (defun python-nav-beginning-of-statement ()
>>    "Move to start of current statement."
>>    (interactive "^")
>>    (while (and (or (back-to-indentation) t)
>>                (not (bobp))
>>                (when (or
>>                       (save-excursion
>>                         (forward-line -1)
>>                         (python-info-line-ends-backslash-p))
>>                       (python-syntax-context 'string)
>>                       (python-syntax-context 'paren))
>>                  (forward-line -1))))
>>    (point-marker))
>
>> (defun python-info-line-ends-backslash-p (&optional line-number)
>>    "Return non-nil if current line ends with backslash.
>> With optional argument LINE-NUMBER, check that line instead."
>>    (save-excursion
>>      (save-restriction
>>        (widen)
>>        (when line-number
>>          (python-util-goto-line line-number))
>>        (while (and (not (eobp))
>>                    (goto-char (line-end-position))
>>                    (python-syntax-context 'paren)
>>                    (not (equal (char-before (point)) ?\\)))
>>          (forward-line 1))
>>        (when (equal (char-before) ?\\)
>>          (point-marker)))))
>
>> They consume most of the time used.  While the first function goes
>> backward, the second goes forward to the end in every loop cycle.  This
>> makes the thing O(n^2), with n being the number of lines of the
>> expression.
>
>> I don't know Python, so I can't make any suggestions.  Who can?  At
>> least, changing the order of `or' expressions in
>> `python-nav-beginning-of-statement' seems to help in the example case:
>
>> (defun python-nav-beginning-of-statement ()
>>    "Move to start of current statement."
>>    (interactive "^")
>>    (while (and (or (back-to-indentation) t)
>>                (not (bobp))
>>                (when (or
>>                       (python-syntax-context 'string)
>>                       (python-syntax-context 'paren)
>>                       (save-excursion
>>                         (forward-line -1)
>>                         (python-info-line-ends-backslash-p)))
>>                  (forward-line -1))))
>>    (point-marker))
>
>> It's also not efficient how often `syntax-ppss' is called all the time.
>
>
>> Regards,
>
>> Michael.
>
>
>
>
>
>

IMO it's a matter of coding style.

IIUC Emacs hackers should be warned somewhere in Elisp manual to code like

python-syntax-context

does. Python.el is not the only place where it's done like this.

It looks nice, but seems to port some dangers WRT speed.