[Top][All Lists]

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

bug#15295: which-func-mode slow in long Python tuple

From: Dale
Subject: bug#15295: which-func-mode slow in long Python tuple
Date: Fri, 06 Sep 2013 19:47:19 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

I happen to have a Python source file that has a relatively long tuple at the module top level, i.e. a Python source file containing:

foo = (
    "item 1",
    "item 2",
    # ...and so on for ~500 lines

I also use which-function-mode. If I go to the end of that tuple and move the cursor in to it, Emacs becomes unusably slow. It will appear to lock up and eat 100% CPU for 10-20 seconds each time I move the cursor within the end of that tuple. Emacs remains responsive at the top of the tuple.

I think this is happening because python-info-current-defun is slow when dealing with long tuples. (Maybe lists, dicts, and other things too; I only tested tuples.) Here's some elisp to produce a test case and benchmark python-info-current-defun:

  (set-buffer (generate-new-buffer "*test*"))
  (insert "foo = (\n")
  (dotimes (_ 500) (insert "    \"bar\",\n"))
  (insert ")\n")
  (forward-line -2)
  (message "%S" (benchmark-run (python-info-current-defun))))

This makes a python-mode buffer named "*test*" containing only a 500-item Python tuple, as in my above example. On my hardware, the above benchmark-run yields a result such as "(7.364507 131 0.9572049999999979)", i.e. 7.3 seconds to run.

Once that *test* buffer is created, feel free to turn on which-function-mode in there and see that Emacs locks up every time you move the cursor around in the end of that tuple. (which-function-mode seems to be taking about twice the time reported by benchmark-run. Perhaps it's calling python-info-current-defun twice?)

I have reproduced this behavior with "emacs -Q" using an Emacs I just built from trunk, looks like revision 114162. (I get Emacs from Git, where the master branch is 0f1532f2fe2.) I have also reproduced this with python.el from the emacs-24 branch, looks like revision 111403.

        Thanks to everyone who develops Emacs, an indispensable tool for me!


reply via email to

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