From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#63622: lisp/progmodes/python.el: performance regression introduced by multiline font-lock Date: Sun, 21 May 2023 09:08:50 +0300 Message-ID: <83zg5yqkr1.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8956"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63622@debbugs.gnu.org To: Tom Gillespie , kobarity , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 21 08:09:31 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q0cG3-0002AB-1m for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 May 2023 08:09:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q0cFc-00012v-3K; Sun, 21 May 2023 02:09:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q0cFa-00012i-L7 for bug-gnu-emacs@gnu.org; Sun, 21 May 2023 02:09:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q0cFa-0006vi-Bb for bug-gnu-emacs@gnu.org; Sun, 21 May 2023 02:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q0cFa-0006yQ-7A for bug-gnu-emacs@gnu.org; Sun, 21 May 2023 02:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 May 2023 06:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63622 X-GNU-PR-Package: emacs Original-Received: via spool by 63622-submit@debbugs.gnu.org id=B63622.168464932026765 (code B ref 63622); Sun, 21 May 2023 06:09:02 +0000 Original-Received: (at 63622) by debbugs.gnu.org; 21 May 2023 06:08:40 +0000 Original-Received: from localhost ([127.0.0.1]:59897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q0cFD-0006xd-L2 for submit@debbugs.gnu.org; Sun, 21 May 2023 02:08:39 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q0cFC-0006xO-MM for 63622@debbugs.gnu.org; Sun, 21 May 2023 02:08:39 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q0cF5-0006sc-MH; Sun, 21 May 2023 02:08:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Q0oeSrmegY10fZuUk/D93RqJzF/VJl22DHjvFR9JkP4=; b=aIam6FJlcZKe Ta6XKspOxriyagwyIXUCxpBv67DnHpuH9Nakbs85q7X0oH0nY2/dXnDdWjOMxo2mSuaJUHPty6I33 F8JlG0A/P6tyxU/48gQieN14SOySNjYnIUuyXjFDGFZxUAamDsiNovweXckeCYpNz2GyTS0YebvH1 A/zYpnawm/5vku7nPbuLD//E8KgegCyOM++WO+xZZ5mVb1KVJBB8DBdOxJ+Q2bqdZrJuTaSvLF3i6 +zhTLTZEETSeJF/NqyRuDMkxurNn/Zaqe/hA7aZ8Bt5C5sbUwmO8XFo41zlkWGgnFyqhfvO7AWXSK 9vwTfWRo2xS+dnjUgBRK3A==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q0cF4-000521-TG; Sun, 21 May 2023 02:08:31 -0400 In-Reply-To: (message from Tom Gillespie on Sat, 20 May 2023 20:14:19 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:262085 Archived-At: > From: Tom Gillespie > Date: Sat, 20 May 2023 20:14:19 -0700 > > The changes in 4915ca5dd4245a909c046e6691e8d4a1919890c8 have > introduced a significant performance regression when editing python > code that contains dictionary structures across multiple lines. > > The current behavior makes Emacs unusable when editing python > dictionaries with more than 20 or so lines. I would suggest reverting > the commit until the performance issue can be addressed. If the problem is so severe, I wonder how come this comes up only now, 9 months after those changes were installed. It probably means these cases are quite rare in practice. Nevertheless, it would be good to solve them, of course. FWIW, python-ts-mode doesn't show performance issues in the examples you posted. > The literal dictionary below is sufficient to demonstrate the issue > and if you bisect and compare the behavior to the immediately prior > commit 31e32212670f5774a6dbc0debac8854fa01d8f92 the difference is > clear. Open the file and hit enter a couple of times and the lag is > obvious (if you can't detect the issue try doubling the number of > lines at the deepest nesting level from 25 to 50). > > By profiling and varying the number of repeated lines (e.g. by > doubling them) it appears that the issue is some lurking quadratic > behavior in syntax-ppss as a result of the changes in 4914ca. In my > testing 25, 50, and 100 lines take 100ms, 800ms, and 5 seconds > respectively to insert a new line while the cursor is inside the outer > most paren. > > Collapsing all the structures into one line hides the issue. The > longer each individual line the more rapid the slowdown. > > The example below is not syntactically correct python, however it > highlights the issue in a way that is clearer than it would be > otherwise. Any chance of your posting some real-life Python code where the issue rears its head? I mean, real-life code that makes sense, not just syntactically correct code invented to make a point? > Despite my previous speculation about the regexp, > the issue is in python-font-lock-extend-region. When > replaced with a no-op the performance returns to normal. kobarity, could you please look into this ASAP? Emacs 29.1 is in late stages of pretest, and I'd like to have this resolved, one way or another, soon enough. TIA. P.S. Tom, please don't change the Subject when posting followups, please use the same Subject for all your messages that discuss this bug. Also, for the record, please state which Emacs version are you using. You didn't use "M-x report-emacs-bug" to submit the bug report, so this and other important information is missing from your OP.