bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15295: python mode slow to unusable


From: Andreas Röhler
Subject: bug#15295: python mode slow to unusable
Date: Sun, 27 Oct 2013 09:01:13 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0

Am 27.10.2013 05:23, schrieb Stefan Monnier:
Could you take a look at this, as well?


         Stefan

"Michael" == Michael Heerdegen <address@hidden> writes:

Alex V. Koval <address@hidden> 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.









reply via email to

[Prev in Thread] Current Thread [Next in Thread]