From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#25122: 24.5; function describe-variable hangs on large variables Date: Wed, 26 Apr 2017 05:57:47 +0200 Message-ID: <87d1bzlt1g.fsf@drachen> References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> <87wpbu7f9i.fsf@users.sourceforge.net> <87r32278wf.fsf@users.sourceforge.net> <87lgs97pg5.fsf@users.sourceforge.net> <87innd6zti.fsf@users.sourceforge.net> <878to653tr.fsf@users.sourceforge.net> <87fuh6s75x.fsf@users.sourceforge.net> <87mvb8paeg.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1493179153 17185 195.159.176.226 (26 Apr 2017 03:59:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Apr 2017 03:59:13 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: 25122@debbugs.gnu.org To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 26 05:59:08 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3E6e-0004NW-2Q for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Apr 2017 05:59:08 +0200 Original-Received: from localhost ([::1]:52520 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d3E6j-00011j-RB for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Apr 2017 23:59:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d3E6d-00011R-FR for bug-gnu-emacs@gnu.org; Tue, 25 Apr 2017 23:59:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d3E6Y-0003Hz-Jk for bug-gnu-emacs@gnu.org; Tue, 25 Apr 2017 23:59:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42212) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d3E6Y-0003Hv-FQ for bug-gnu-emacs@gnu.org; Tue, 25 Apr 2017 23:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1d3E6Y-0000sS-7s for bug-gnu-emacs@gnu.org; Tue, 25 Apr 2017 23:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2017 03:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25122 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch fixed Original-Received: via spool by 25122-submit@debbugs.gnu.org id=B25122.14931790843306 (code B ref 25122); Wed, 26 Apr 2017 03:59:02 +0000 Original-Received: (at 25122) by debbugs.gnu.org; 26 Apr 2017 03:58:04 +0000 Original-Received: from localhost ([127.0.0.1]:40411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3E5c-0000rF-16 for submit@debbugs.gnu.org; Tue, 25 Apr 2017 23:58:04 -0400 Original-Received: from mout.web.de ([212.227.17.12]:61016) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3E5Z-0000qk-8G for 25122@debbugs.gnu.org; Tue, 25 Apr 2017 23:58:01 -0400 Original-Received: from drachen.dragon ([88.73.21.103]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MHowb-1d6nWN0Shp-003e3Y; Wed, 26 Apr 2017 05:57:42 +0200 In-Reply-To: <87mvb8paeg.fsf@users.sourceforge.net> (npostavs's message of "Sat, 22 Apr 2017 14:25:27 -0400") X-Provags-ID: V03:K0:43F2CflsX4zfqntz/uueH9p7/aiVignFl6+xjhEM/1aIM09QVyg NAm+kaWSXXi7rJCWlXRMZmMODFpyrQwNFpotgb+tA/7fazD1LgJiaRhyO4zTqp/WMxVB6j2 gTQP1waJ8IKGgST87Jq0u2kjoalf2CNsCU+mVz8wxuhwnre3NrUyL+6oCKXc2tvWSvtcbyK QFqXIjye4S4hVvJ6BXdIw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Sh3Yb0vxIHc=:hbI3MrRQDJscTNBldJnDJC f5o/KMl6SlbiYfD7QEe933vDhM4Ruo8jksOPB71XcB5Wn6dm5gpw01ZBQ0+L4iSUvZ7JN80Zu +LRSjoQoUBAhAZ0wIQcR2vcteW0ZG0tcvqlIdQwCYRCBqcCJM/wV8yT72KqG7x0SX/4rwWlR6 bbe5SUuM7Oy32DtDxEFupdiBMqbosa4CUviVBi+W9vyP9MCabwzNYgh/YPH3LTtz1xk8bwAq1 6CwrUKRbKQnarkclE5dZC3SLNzXhxvnDh277bl/duN7hROdXow68mGo0syFEkwMagvoFL4i8l EDACRu9vDg8NI8YhRwdfgapSiylDLwvTvHgT6SPolXxzyN+ePIFgMC1TMt35Nx3yuvY9DFaHr 1KCSdRuYB+2naPUN7rDK9iKNAD4qMT/4SIfaaZFGNzCypHIyUduEYTZUo+nNOReGaFVxFfUc0 OBXGcs03to4YcmYLu8xUULGarK/nBvJByG4auOUYJg2fIJ5MpDSYyf7/vkUrua5n7jeByc/W4 VNfR/FCDOaaRWwqGAqtE3x5hAILjrx9Wr4ywnSbyynFVdvKul6O/8F7w8PwfeeGRYzCDFan+l GIW+36gJnZ0G5AMZAT4u8ZVExWnGgDuLYPbyJLucMZL0e7FV2TuLPHYi4GiMYi56TFiYirzMh k3qcmgRib1OpA9FZHJPYMy01NvKE3P71ScP9TC4C9taXEpbAcMkaIqOztGA4ce75YT8/0TdMm XOfI/4X9q4mbd7UGaYXvNz/E2J8EJiOreD6MCGKfOOpeCzsLpBRPJSLj/ivRbE2NFFtY4XcZ X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:131991 Archived-At: Hi Noam, > > I intend to close this bug as fixed after merging these, as this does > > fix the performance bug. I have a question: how much performance gain can I expect from your changes? My use case is the following: "el-search" has now an occur-like operation mode. It copies all matches (i.e. s-expressions) into an *El Occur* buffer. Matches can be tiny (like `1') or arbitrarily large. Since most expressions don't start at column 0 in their source buffer (unless they are top-level), I have to remove the amount of additional indentation from all but the first line of a match. Well - not from all, that's where it gets complicated - there are cases where this is wrong, like in strings and some comments. To have a sane solution, I just used `indent-region' to reindent the expression in the occur buffer. This works great, but `indent-region' was so slow that it took up to 50 percent of the whole running time of the occur search. With an naive alternative approach (just remove additional indentation from lines where it makes sense (whereby finding out whether it "makes sense" involves running syntax scanning)), I get an improvement of a factor around five or ten relative to `indent-region' for reindenting. Would you expect your improved `indent-region' is fast enough now so that it makes sense that I switch back to it in my code? Is the running time now something close to O(number of lines to indent)? Thanks, Michael.