From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#60691: 29.0.60; Slow tree-sitter font-lock in ruby-ts-mode Date: Sun, 29 Jan 2023 00:25:20 -0800 Message-ID: <90D8581D-C543-43EE-8BEB-51B5AFBCBAEE@gmail.com> References: <867cxv3dnn.fsf@mail.linkov.net> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="526"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60691@debbugs.gnu.org, juri@linkov.net To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 29 09:26:21 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 1pM313-000AZ6-AE for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Jan 2023 09:26:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pM30t-0002NO-32; Sun, 29 Jan 2023 03:26:13 -0500 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 1pM30m-0002Mn-GE for bug-gnu-emacs@gnu.org; Sun, 29 Jan 2023 03:26:05 -0500 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 1pM30m-0007TI-8E for bug-gnu-emacs@gnu.org; Sun, 29 Jan 2023 03:26:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pM30k-0001g1-87 for bug-gnu-emacs@gnu.org; Sun, 29 Jan 2023 03:26:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <867cxv3dnn.fsf@mail.linkov.net> Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Jan 2023 08:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60691 X-GNU-PR-Package: emacs Original-Received: via spool by 60691-submit@debbugs.gnu.org id=B60691.16749807416416 (code B ref 60691); Sun, 29 Jan 2023 08:26:02 +0000 Original-Received: (at 60691) by debbugs.gnu.org; 29 Jan 2023 08:25:41 +0000 Original-Received: from localhost ([127.0.0.1]:42239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pM30O-0001fQ-Vi for submit@debbugs.gnu.org; Sun, 29 Jan 2023 03:25:41 -0500 Original-Received: from mail-pj1-f41.google.com ([209.85.216.41]:45717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pM30M-0001f6-81 for 60691@debbugs.gnu.org; Sun, 29 Jan 2023 03:25:40 -0500 Original-Received: by mail-pj1-f41.google.com with SMTP id nm12-20020a17090b19cc00b0022c2155cc0bso8433016pjb.4 for <60691@debbugs.gnu.org>; Sun, 29 Jan 2023 00:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=UPbzADtHQ8/4BAGuJ9oO2Evj3IM+Czlfa1U92qLTR9o=; b=HokYOUp31EjDlD/L+ZgnB7FB6J8C2+mE/OKxI+HGwp1WaovNxuh2Z+6MADjJSFWyTZ JZ6slj5X3URYQS0lme+1vGkjN29qdfcM9pSg8sCo8dmRT050KUUf6J3AZP2M5vhwa7Ci zYzQJ2wxFt00guf5JW/0AWKMAQdmwmQv3B8+gt0hswpF3geRJ+0FEU5uNn/Mb/5+xNLi KbTS1nKMGAbZFm20A1jT2P3MA6joYDQpEiZJw/h+gQ7Hf1aWoZwxyvXoOKdWjY8vnhqn 6FH/1DsL2QMmotSB9WFCPwfg47OT2Lk8gX6b2Xg/Jlhk39jvYvN51uYhInYWB2s8IxBy 81wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UPbzADtHQ8/4BAGuJ9oO2Evj3IM+Czlfa1U92qLTR9o=; b=pdgGF45Fz93emXMfjsfSIn3DPvmxeRP70Wqj8hgVh8TODTUFvqVJGTGslfdWT3NimX e9VsQJD1W/TyTNg4tIjORYFcNpx1T2xswCVBpLdZJ3mexTwtyx0ZelxmxZsGXJ7mf2qi edwFksjC5YmhYC/ES0rtqLQr3u0lNq6m/tsdUY/WwX2YApFkJvO2uDT2iEN7spVPLIUl IkrTDluNwqIrzOXe6BNVPQet+ONYGD07JhtmMfDRajuSedC83W0W+h3Orc01k7CnYLZL qp80FCDYvR/3QxH6ycPIs8rbzmpDQ02/nacQVR83ITT0/M+6b4npp7ivX1a2pGlxgN4A 56aA== X-Gm-Message-State: AO0yUKWn8o3mOGRVTJT9/dmclnS9TVpQlAOXh60ng9QZ/6iHp9D3f2Rg bwmhBG5YwCUbE+A3EAYmBk4= X-Google-Smtp-Source: AK7set+fyfk1b8AivjQ6l/LkJLINWtTjGtyE9sn1UDLuJfp3i+Koh0YhAu0Gy6N/wy/srFeUwr/JXw== X-Received: by 2002:a05:6a20:7da3:b0:bc:cc66:60b7 with SMTP id v35-20020a056a207da300b000bccc6660b7mr2232823pzj.51.1674980732339; Sun, 29 Jan 2023 00:25:32 -0800 (PST) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id t16-20020a639550000000b0046fefb18a09sm4707596pgn.91.2023.01.29.00.25.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jan 2023 00:25:32 -0800 (PST) X-Mailer: Apple Mail (2.3731.300.101.1.3) 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:254340 Archived-At: Dmitry Gutov writes: > On 21/01/2023 00:24, Yuan Fu wrote: >>=20 >>> On Jan 19, 2023, at 10:28 AM, Dmitry Gutov wrote: >>> >>> Hi Yuan, >>> >>> On 18/01/2023 08:50, Yuan Fu wrote: >>>>>>> Should treesit--font-lock-fast-mode be locally bound inside that >>>>>>> function, so that it's reset between chunks? Or maybe the = condition >>>>>>> for its enabling should be tweaked? E.g. I don't think there are = any >>>>>>> particularly large or deep nodes in ruby.rb's parse tree. It's a >>>>>>> very shallow file. >>>>> >>>>> Yeah that is a not-very-clever hack. I=E2=80=99ve got an idea: I = can add a C >>>>> function that checks the maximum depth of a parse tree and the = maximum >>>>> node span, and turn on the fast-mode if the depth is too large or = a node >>>>> is too wide. And we do that check once before doing any = fontification. >>>>> >>>>> I=E2=80=99ll report back once I add it. >>>> I wrote that function. But I didn=E2=80=99t end up using it. = Instead I added a >>>> "grace count", so that the query time has to be longer than the >>>> threshold 5 times before we switch on the fast mode instead of 1. >>>> My main worry is that simply looking at the parse tree would not = catch >>>> all the case where there will be expensive queries. >>> >>> That might be true, but a criterion that doesn't specify conditions = exactly can give no guarantee against false positives. >> The condition is =E2=80=9Cquery is (consistently) slow=E2=80=9D, = that=E2=80=99s why I >> thought measuring the time is the most direct way. > > The benchmark itself might be artificial, in that it's measuring the > font-lock of a specific buffer, in whole, for 1000 iterations. But > Juri must have come up with the original report based on real usage > scenario. > > OTOH, the scenario which it might correspond to, is used typing in the > same buffer for a long time (triggering thousands of refontifications, > possibly partial ones). I don't know if it's feasible to try to > reproduce it specifically. But, again, anything that can happen once > can happen 4 more times. > >>>> Could you try the latest commit and see if the fast mode still = switches >>>> on when it shouldn=E2=80=99t? >>> >>> At first it seemed to help, but then I switched the major mode a >>> couple more times, and ran the benchmark twice more, and the "fast >>> mode" switched on again. >>> >>> Which seems to make sense: there is no resetting the counter, right? >>> >>> So if previously it happened once somehow during a certain scenario, = now I have to repeat the same scenario 4 times, and the condition is = met. >> I was hoping that the scenario only happen once, oh well :-) I=E2=80=99= ll >> change the decision based on analyzing the tree=E2=80=99s dimension: = too >> deep or too wide activates the fast mode. Let=E2=80=99s see how it = works. > > Thank you, let me know when it's time to test again. Sorry for the delay. Now treesit-font-lock-fontify-region uses treesit-subtree-stat to determine whether to enable the "fast mode". Now it should be impossible to activate the fast mode on moderately sized buffers. Yuan