From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 06 20:48:00 2013 Received: (at submit) by debbugs.gnu.org; 7 Sep 2013 00:48:00 +0000 Received: from localhost ([127.0.0.1]:45340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VI6gx-0006cZ-Tu for submit@debbugs.gnu.org; Fri, 06 Sep 2013 20:48:00 -0400 Received: from eggs.gnu.org ([208.118.235.92]:57867) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VI6gs-0006cH-UM for submit@debbugs.gnu.org; Fri, 06 Sep 2013 20:47:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VI6ge-0006Tg-0r for submit@debbugs.gnu.org; Fri, 06 Sep 2013 20:47:49 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:58673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VI6gd-0006SY-TV for submit@debbugs.gnu.org; Fri, 06 Sep 2013 20:47:39 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VI6gW-0006Xy-FF for bug-gnu-emacs@gnu.org; Fri, 06 Sep 2013 20:47:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VI6gN-0006Js-UE for bug-gnu-emacs@gnu.org; Fri, 06 Sep 2013 20:47:32 -0400 Received: from mail-ie0-f178.google.com ([209.85.223.178]:44244) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VI6gN-0006Jl-PS for bug-gnu-emacs@gnu.org; Fri, 06 Sep 2013 20:47:23 -0400 Received: by mail-ie0-f178.google.com with SMTP id f4so8727728iea.9 for ; Fri, 06 Sep 2013 17:47:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=gLh/2EB/PIaoe/zhOmZacIhwv5jbN9JGUyKdxfyQHR8=; b=kC9y8rTd7nBe+Gmn0jkKxt+WqdQVklvi8ckt1Xr4E05vm1INd3NRaRucG3vr5JPOra Cg93kNBXrcdX2HjrFXRPZS7hR1Vw20qlwD7oyMp1oLB+YDypdBa2M4gfdO9xI63DGx7+ gBH+DKExMKquWo/O8rfg+uvSw/DUVpkGg172TFPuTeKFXURlL4fEP5tJxhyZykOR0e6+ 5d01XOPQt1JZtDDoiw4E+//MryE6htjSveZtNGTNSrjLJ5f/wvi2cfJEyV066x8q9l0v uCkf+pzfmwWKVgiVH7NwaH1QYpGp+k69aDsr1nFiel+DQb0cSWvJQHgRs+3w12M06Us2 zShw== X-Gm-Message-State: ALoCoQnmvJsC3J3mvb9IjvR+ssyvv5CNllmBPUeY/00DIIjNovDGV5sfOGlAtlJ7ZPxYrTlTgDGW X-Received: by 10.43.125.4 with SMTP id gq4mr3297217icc.1.1378514841326; Fri, 06 Sep 2013 17:47:21 -0700 (PDT) Received: from dale.caliginous.net (c-50-140-165-4.hsd1.in.comcast.net. [50.140.165.4]) by mx.google.com with ESMTPSA id lp9sm514399igb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Sep 2013 17:47:20 -0700 (PDT) Message-ID: <522A7797.4020903@codefu.org> Date: Fri, 06 Sep 2013 19:47:19 -0500 From: Dale User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: which-func-mode slow in long Python tuple Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.4 (---) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 26 05:17:05 2013 Received: (at 15295) by debbugs.gnu.org; 26 Oct 2013 09:17:05 +0000 Received: from localhost ([127.0.0.1]:44647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZzzV-0005t9-GC for submit@debbugs.gnu.org; Sat, 26 Oct 2013 05:17:05 -0400 Received: from monitor1-valor.halogen.kharkov.ua ([195.24.253.71]:42004 helo=mail2.ua2web.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZzzT-0005sf-FS for 15295@debbugs.gnu.org; Sat, 26 Oct 2013 05:17:04 -0400 Received: from [195.24.252.130] (helo=avk-br.local) by mail2.ua2web.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80.1) (envelope-from ) id 1VZzzQ-000795-8i for 15295@debbugs.gnu.org; Sat, 26 Oct 2013 12:17:00 +0300 From: Alex V. Koval To: 15295@debbugs.gnu.org Subject: python mode slow to unusable User-Agent: Notmuch/0.16 (http://notmuchmail.org) Emacs/24.2.1 (x86_64-pc-linux-gnu) Date: Sat, 26 Oct 2013 12:16:56 +0300 Message-ID: <87y55gie7r.fsf@halogen-dg.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 15295 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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) In fact, when I enable which-function-mode and just try to open one of our project files, it reads it 62 seconds. *Same* file opened with emacs 24.2 reads < 1second. Same thing happens when I try to call 'help-imenu' - 46 seconds. In emacs 24.2 - less then 1 second. I have this bug in version 24.3 and 'bzr' current: * Emacs branch: trunk * Revision: 114814 * Emacs version number: 24.3.50 Please tell me what additional information should I provide. Not very big expert in Lisp but may try to debug it more to detail. WBR, Alex From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 26 07:39:36 2013 Received: (at 15295) by debbugs.gnu.org; 26 Oct 2013 11:39:36 +0000 Received: from localhost ([127.0.0.1]:44857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Va2DO-00023N-74 for submit@debbugs.gnu.org; Sat, 26 Oct 2013 07:39:34 -0400 Received: from mout.web.de ([212.227.15.4]:61959) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Va2DK-000235-Ni for 15295@debbugs.gnu.org; Sat, 26 Oct 2013 07:39:31 -0400 Received: from drachen.dragon ([90.187.153.26]) by smtp.web.de (mrweb001) with ESMTPA (Nemesis) id 0MKr7w-1Va2DB42nw-0005db for <15295@debbugs.gnu.org>; Sat, 26 Oct 2013 13:39:24 +0200 From: Michael Heerdegen To: Alex V. Koval Subject: Re: bug#15295: python mode slow to unusable References: <522A7797.4020903@codefu.org> <87y55gie7r.fsf@halogen-dg.com> Date: Sat, 26 Oct 2013 13:39:21 +0200 In-Reply-To: <87y55gie7r.fsf@halogen-dg.com> (Alex V. Koval's message of "Sat, 26 Oct 2013 12:16:56 +0300") Message-ID: <87fvrofehi.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:MGbeD1WRgOneLlY3k5rbG32u+4dgaVEa/2hu2vjxbEE6/mnrkuE sbHVZn2nVsAbZWhsBfVx1AII6DQ+v/h+p8Elq0z22mksbZ31Xu71LUqPvaj1oF/UJurHRro e59UE+kXbKK7xeFZsi9KrAT1lnG7Kc2GTFz6EM/4NuoZaABmS29b2dqAaQLTGUAwh1mljNY UnRVGCV9FxWUlYnQUPGtA== X-Spam-Score: -0.4 (/) X-Debbugs-Envelope-To: 15295 Cc: 15295@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) Alex V. Koval 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 27 00:23:58 2013 Received: (at 15295) by debbugs.gnu.org; 27 Oct 2013 04:23:58 +0000 Received: from localhost ([127.0.0.1]:46871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaHtO-00033t-B2 for submit@debbugs.gnu.org; Sun, 27 Oct 2013 00:23:58 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:26099) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaHtN-00033h-78 for 15295@debbugs.gnu.org; Sun, 27 Oct 2013 00:23:57 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFLd/hu/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kE4d/AwkGt0siiUCRCgOSWpIggV6DEw X-IPAS-Result: Av4EABK/CFFLd/hu/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kE4d/AwkGt0siiUCRCgOSWpIggV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="36440882" Received: from 75-119-248-110.dsl.teksavvy.com (HELO pastel.home) ([75.119.248.110]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 27 Oct 2013 00:23:51 -0400 Received: by pastel.home (Postfix, from userid 20848) id 7BBFE60038; Sun, 27 Oct 2013 00:23:51 -0400 (EDT) From: Stefan Monnier To: =?windows-1252?Q?Fabi=E1n?= Ezequiel Gallina Subject: Re: bug#15295: python mode slow to unusable Message-ID: References: <522A7797.4020903@codefu.org> <87y55gie7r.fsf@halogen-dg.com> <87fvrofehi.fsf@web.de> Date: Sun, 27 Oct 2013 00:23:51 -0400 In-Reply-To: <87fvrofehi.fsf@web.de> (Michael Heerdegen's message of "Sat, 26 Oct 2013 13:39:21 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 15295 Cc: 15295@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Could you take a look at this, as well? Stefan >>>>> "Michael" == Michael Heerdegen writes: > Alex V. Koval 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 27 03:59:07 2013 Received: (at submit) by debbugs.gnu.org; 27 Oct 2013 07:59:07 +0000 Received: from localhost ([127.0.0.1]:47145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaLFa-00007b-Dk for submit@debbugs.gnu.org; Sun, 27 Oct 2013 03:59:06 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39988) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaLFX-000072-0v for submit@debbugs.gnu.org; Sun, 27 Oct 2013 03:59:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VaLFL-00034P-0K for submit@debbugs.gnu.org; Sun, 27 Oct 2013 03:58:57 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:58887) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VaLFK-00034L-Ti for submit@debbugs.gnu.org; Sun, 27 Oct 2013 03:58:50 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VaLFE-0006WY-UG for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2013 03:58:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VaLF9-00033Z-2t for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2013 03:58:44 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]:56219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VaLF8-00033F-P8 for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2013 03:58:38 -0400 Received: from purzel.sitgens (brln-4d0c0509.pool.mediaWays.net [77.12.5.9]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0ME45v-1VTWHD19PL-00GsJ0; Sun, 27 Oct 2013 08:58:36 +0100 Message-ID: <526CC849.7020500@easy-emacs.de> Date: Sun, 27 Oct 2013 09:01:13 +0100 From: =?ISO-8859-15?Q?Andreas_R=F6hler?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: Re: bug#15295: python mode slow to unusable References: <522A7797.4020903@codefu.org> <87y55gie7r.fsf@halogen-dg.com> <87fvrofehi.fsf@web.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:3NoC/e05w2DBTFm1oFh13132U0Hrnf/+4K9FDcyLoXS kOsaFJmhdXphjmC4f4sB5JAXJLaPilDz5/Ciq/pOG7oSAo4Z2Z 4prXtWhRMl4tCrIevZXxwifiA+6rVwLaw3dScZSTpIad5v5sAH CKj4a49LI1lTb03NFzGP5aHK9fAR3yKOCzEeTRYe8XLGQHqJNz en8dY+M4wr+ootz6cJhN4mjfOWBOBbgJMDz12Nnfxn/SPOWerQ QP5XxdjPMMMqPqwRudvjkujv+RCPXrkPmZ9hKFAVvtIsLGB20l 2h5iKvWRfwqhBFL8snZI2C2B2pyNU3LibO7u1OifIhsAoYmTh6 ctCpe0qeOethcarLZXY4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Am 27.10.2013 05:23, schrieb Stefan Monnier: > Could you take a look at this, as well? > > > Stefan > >>>>>> "Michael" == Michael Heerdegen writes: > >> Alex V. Koval 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 24 15:08:42 2013 Received: (at 15295-done) by debbugs.gnu.org; 24 Dec 2013 20:08:42 +0000 Received: from localhost ([127.0.0.1]:39652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvYHR-0003ie-Ny for submit@debbugs.gnu.org; Tue, 24 Dec 2013 15:08:42 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:37906) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvYHP-0003iS-MQ for 15295-done@debbugs.gnu.org; Tue, 24 Dec 2013 15:08:40 -0500 Received: from [181.164.60.202] (port=50247 helo=localhost) by fencepost.gnu.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1VvYHN-0000eC-Jf for 15295-done@debbugs.gnu.org; Tue, 24 Dec 2013 15:08:38 -0500 User-agent: mu4e 0.9.9.6pre2; emacs 24.3.1 From: fgallina@gnu.org (=?utf-8?Q?Fabi=C3=A1n?= Ezequiel Gallina) To: 15295-done@debbugs.gnu.org Subject: Date: Tue, 24 Dec 2013 17:08:09 -0300 Message-ID: <87sitij9li.fsf@tata.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -3.6 (---) X-Debbugs-Envelope-To: 15295-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.6 (---) Fixed in revno 115736. Thanks Dale for such detailed recipe. This patch banishes initial thoughts of `python-syntax-context' being a bad idea. `python-syntax-context' is nothing than a thin semantic wrapper over `syntax-ppss'. It makes code easier to grasp for newcomers to Elisp and has almost no impact on itself, it's optional argument is a `syntax-ppss' list which can be used instead to lower the amount of calls to it (as it is happening in this new patch I've just committed). The problem here was that `python-nav-beginning-of-statement' was coded awfully (looking for the statement beginning line by line). Now it should be extremely fast compared to that. Using OP's suggested recipe, here are the elp results for when which-func is triggered inside the big tuple: python-info-current-defun 2 0.003719249 0.0018596245 python-nav-beginning-of-defun 2 0.0036946010 0.0018473005 python-nav--beginning-of-defun 2 0.003685751 0.0018428755 python-nav-backward-block 2 0.001836524 0.000918262 python-nav-forward-block 2 0.0018315750 0.0009157875 python-info-looking-at-beginning-of-defun 6 0.000889166 0.0001481943 python-nav-beginning-of-statement 4 0.000437251 0.0001093127 python-syntax-context-type 6 5.009e-06 8.348...e-07 And this is the benchmark-run result: (0.020715153 0 0.0) Regards, Fabián. From unknown Sat Sep 06 03:07:47 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 22 Jan 2014 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator