From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: kobarity Newsgroups: gmane.emacs.bugs Subject: bug#63622: lisp/progmodes/python.el: performance regression introduced by multiline font-lock Date: Sun, 21 May 2023 18:31:50 +0900 Message-ID: References: <83zg5yqkr1.fsf@gnu.org> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: multipart/mixed; boundary="Multipart_Sun_May_21_18:31:47_2023-1" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21081"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?Q?Goj=C5=8D?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Cc: Eli Zaretskii , Stefan Monnier , 63622@debbugs.gnu.org To: Tom Gillespie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 21 11:33:28 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 1q0fRP-0005JT-0J for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 May 2023 11:33:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q0fR3-00067l-Qt; Sun, 21 May 2023 05:33:05 -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 1q0fR1-00067F-JG for bug-gnu-emacs@gnu.org; Sun, 21 May 2023 05:33:03 -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 1q0fR0-00020J-El for bug-gnu-emacs@gnu.org; Sun, 21 May 2023 05:33:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q0fR0-0004CJ-AR for bug-gnu-emacs@gnu.org; Sun, 21 May 2023 05:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: kobarity Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 May 2023 09:33: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.168466153916071 (code B ref 63622); Sun, 21 May 2023 09:33:02 +0000 Original-Received: (at 63622) by debbugs.gnu.org; 21 May 2023 09:32:19 +0000 Original-Received: from localhost ([127.0.0.1]:60029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q0fQI-0004B8-Ki for submit@debbugs.gnu.org; Sun, 21 May 2023 05:32:18 -0400 Original-Received: from mail-pf1-f180.google.com ([209.85.210.180]:60902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q0fQF-0004Ak-6H for 63622@debbugs.gnu.org; Sun, 21 May 2023 05:32:17 -0400 Original-Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-64d1a0d640cso2556399b3a.1 for <63622@debbugs.gnu.org>; Sun, 21 May 2023 02:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684661529; x=1687253529; h=mime-version:user-agent:references:in-reply-to:subject:cc:to:from :message-id:date:from:to:cc:subject:date:message-id:reply-to; bh=XOF79bhjr/0+4j6+r/KPqY7LeH5m7kMSPSsXJ3eE2I0=; b=Kz4f2T/P62Jv9yvJWuF0mijXPYZvjx4SSWlY4ZqFEm29W30BLnyFvKX62aZwGdhcSb R3A+BJeyZ9x9aaoIbSId29p3yVEL2fBsYNepFOxs2Rh0MQyXyDM1JNry+XvJG1ss1gia Isu1sijpOSSbAVtORU2ae0p/9xnVnYF3i4Gi5zotqks+gdr+GwwNyQWFtyrnBQZN4mjS PsWCEYwi56KSLAB+v1aCb95eOfaJ8HEI+iMuF0OLCUWGjNnqr/IsGox/32hDdrKVA8or JuIl6LN8HjN+FhIVH8IlVZEfqcNPhkDm9QPZrZN9Qx6pIJ2w9VdiSrqLG/iFgkSOdbVI Xs8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684661529; x=1687253529; h=mime-version:user-agent:references:in-reply-to:subject:cc:to:from :message-id:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XOF79bhjr/0+4j6+r/KPqY7LeH5m7kMSPSsXJ3eE2I0=; b=lzFe7NMBPJHhrMKBF9oDfMsDpczsD2+kb9BMG78ez3FU9sYxSVKBWP2top/aePSEuu Zv9woicmYQP7Ta1tBokmSUJ6gaYmFi24KUaQTcrswJ0Qm5VSykFWV6TIjCVkUu38pKSK 6rXbxo8jFIRPX9fKwUPP8GJO/o0DN/HXMOAGJy+By9DccbcH6aknIjQbAGFbs3jpyoP3 ZWUsFKUNOfGuKegFfOvECyfKQO9E4lSQny1IvvwGjknWFA/PoDYcVyx1Xb8+9OcUOnYE A5iiu/WGDnE214i9YGafv8RRi4a0VpuMBP3Ylf5ozNiozK9W07RI1ppgtDN6VrPw4aPT DYfg== X-Gm-Message-State: AC+VfDyy9b6AQXecYJNltQ7BZl9rYcOsgKpBF2XTnsQNXIWD0wJcdALz K93vho3r/ivOXyxuNC27MP4= X-Google-Smtp-Source: ACHHUZ42pFABH0Uf0ZHmjdR8n8Z68gDfHtwX7o2NseXWfbrzqEMlEiqNqAU/K1GeKkBmRhWwceGrag== X-Received: by 2002:a05:6a20:914e:b0:104:f534:6c8d with SMTP id x14-20020a056a20914e00b00104f5346c8dmr7533394pzc.33.1684661529142; Sun, 21 May 2023 02:32:09 -0700 (PDT) Original-Received: from localhost (58x12x133x161.ap58.ftth.ucom.ne.jp. [58.12.133.161]) by smtp.gmail.com with ESMTPSA id v17-20020a63f851000000b0052c3f0ae381sm2496036pgj.78.2023.05.21.02.32.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 May 2023 02:32:08 -0700 (PDT) In-Reply-To: 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:262098 Archived-At: --Multipart_Sun_May_21_18:31:47_2023-1 Content-Type: text/plain; charset=US-ASCII Tom Gillespie wrote: > The changes in 4915ca5dd4245a909c046e6691e8d4a1919890c8 have > introduced a significant performance regression when editing python > code that contains dictionary structures across multiple lines. Hi Tom and Eli, Thanks for bringing this issue to my attention. > As far as I can tell the existing implementation for python font locking > has some quadratic behavior that is revealed when a region is extended > inside a nested dictionary with multiple lines. I agree. It seems to me that it is not python-font-lock-extend-region itself that is slow, but rather font-lock's processing of the area extended by it. So one workaround would be to limit the number of lines to be extended, as in the attached patch. If this limit is exceeded, the area or the entire buffer must be font-locked manually later. What do you think of this idea? Even if we adopt this idea, there remain several points to consider: - How many lines are appropriate for the limit? - Is it better to make the limit customizable? - python-ts-mode should be excluded for this limit? --Multipart_Sun_May_21_18:31:47_2023-1 Content-Type: application/octet-stream; type=patch; name="0001-Workaround-performance-degradation-when-editing-mult.patch" Content-Disposition: attachment; filename="0001-Workaround-performance-degradation-when-editing-mult.patch" Content-Transfer-Encoding: 7bit >From 3224ef9d2718c85281f1fa789708efb0b5aa5fff Mon Sep 17 00:00:00 2001 From: kobarity Date: Sun, 21 May 2023 17:50:09 +0900 Subject: [PATCH] Workaround performance degradation when editing multiline Python expression * lisp/progmodes/python.el (python-font-lock-extend-max-lines): New variable. (python-font-lock-extend-region): Limit extending the region to python-font-lock-extend-max-lines. (Bug#63622) --- lisp/progmodes/python.el | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el index 6fc05b246a6..82d15536de0 100644 --- a/lisp/progmodes/python.el +++ b/lisp/progmodes/python.el @@ -869,16 +869,25 @@ python-font-lock-keywords Which one will be chosen depends on the value of `font-lock-maximum-decoration'.") +(defvar python-font-lock-extend-max-lines 10 + "Maximum number of lines to extend the font-lock region. +This is a workaround to avoid performance degradation when +editing expressions that span many lines. See Emacs Bug#63622.") + (defun python-font-lock-extend-region (beg end _old-len) "Extend font-lock region given by BEG and END to statement boundaries." (save-excursion (save-match-data (goto-char beg) (python-nav-beginning-of-statement) - (setq beg (point)) + (when (<= (- (line-number-at-pos beg) (line-number-at-pos)) + python-font-lock-extend-max-lines) + (setq beg (point))) (goto-char end) (python-nav-end-of-statement) - (setq end (point)) + (when (<= (- (line-number-at-pos) (line-number-at-pos end)) + python-font-lock-extend-max-lines) + (setq end (point))) (cons beg end)))) -- 2.34.1 --Multipart_Sun_May_21_18:31:47_2023-1--