GNU bug report logs - #15295
which-func-mode slow in long Python tuple

Previous Next

Full log

View this message in rfc822 format

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: 15295 <at> debbugs.gnu.org
Subject: bug#15295: python mode slow to unusable
Date: Sun, 27 Oct 2013 09:01:13 +0100

Am 27.10.2013 05:23, schrieb Stefan Monnier:
> Could you take a look at this, as well?
>
>
>          Stefan
>
>>>>>> "Michael" == Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>
>> Alex V. Koval <alex <at> 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.

Previous Next

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