From: Dale <dale@codefu.org>
To: 15295@debbugs.gnu.org
Subject: bug#15295: which-func-mode slow in long Python tuple
Date: Fri, 06 Sep 2013 19:47:19 -0500 [thread overview]
Message-ID: <522A7797.4020903@codefu.org> (raw)
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:
----------
(progn
(set-buffer (generate-new-buffer "*test*"))
(python-mode)
(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!
Dale
next reply other threads:[~2013-09-07 0:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-07 0:47 Dale [this message]
2013-10-26 9:16 ` bug#15295: python mode slow to unusable Alex V. Koval
2013-10-26 11:39 ` Michael Heerdegen
2013-10-27 4:23 ` Stefan Monnier
2013-10-27 8:01 ` Andreas Röhler
2013-12-24 20:08 ` bug#15295: Fabián Ezequiel Gallina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=522A7797.4020903@codefu.org \
--to=dale@codefu.org \
--cc=15295@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.