From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#60691: 29.0.60; Slow tree-sitter font-lock in ruby-ts-mode Date: Thu, 19 Jan 2023 20:28:41 +0200 Message-ID: <4b75a1e5-ace9-2312-54f7-c1de9c798d9c@yandex.ru> References: <867cxv3dnn.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20414"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: 60691@debbugs.gnu.org, juri@linkov.net To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 19 19:29:20 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 1pIZf5-00057g-Ct for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 19 Jan 2023 19:29:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pIZev-0006F4-Lt; Thu, 19 Jan 2023 13:29:09 -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 1pIZeo-00061p-LE for bug-gnu-emacs@gnu.org; Thu, 19 Jan 2023 13:29:04 -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 1pIZeo-00032M-Dh for bug-gnu-emacs@gnu.org; Thu, 19 Jan 2023 13:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pIZen-0004rf-Kl for bug-gnu-emacs@gnu.org; Thu, 19 Jan 2023 13:29:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Jan 2023 18:29:01 +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.167415293118680 (code B ref 60691); Thu, 19 Jan 2023 18:29:01 +0000 Original-Received: (at 60691) by debbugs.gnu.org; 19 Jan 2023 18:28:51 +0000 Original-Received: from localhost ([127.0.0.1]:44727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pIZec-0004rE-Sx for submit@debbugs.gnu.org; Thu, 19 Jan 2023 13:28:51 -0500 Original-Received: from mail-ed1-f50.google.com ([209.85.208.50]:35610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pIZeb-0004r2-CT for 60691@debbugs.gnu.org; Thu, 19 Jan 2023 13:28:50 -0500 Original-Received: by mail-ed1-f50.google.com with SMTP id y19so3998660edc.2 for <60691@debbugs.gnu.org>; Thu, 19 Jan 2023 10:28:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=IEtOXFc3EtCB2Fm2g8Vnr3oxuso2rd41z//ttnErIxk=; b=flnvTt75gLO+EUDU7nxPZIxHSAkGbRBwQ9Bc1llqjjz8hrgoBdkIzVsbwvEOrODtT5 ep3aqRhH23NBb310P1NPev5tlSiIazdcWNhegqqnek8dOCLhW6CPe9qkzMsLlrH7tQyk DekQOLoHOhGV1P2/3gx/YqemAML+I9jk6HVt/fO4Futwu5Mmd8C1svtSduXYxFlngttp qRCHJ1BFWDPtSpwaadVHRMhhTEEshhJs/dcAKRQ5gkHYu3zCf5jNpLcu7IQFUd0Yu7fZ DgB42QaAodMAcZllbzUiqY/AbqFuPHZISDOp3Hs9FJcT1O2qYmdJi/HaxXA/Vg9GdEhS cIFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IEtOXFc3EtCB2Fm2g8Vnr3oxuso2rd41z//ttnErIxk=; b=8CoCWn3ndFC46B7fu5h3J10GhudLQw77aEOUTVg1HO1HzL2Rs0fijXLxG60fVyRxGA r+hbMtXI7nyn3n64yx6TsWdUdRdNuBSB+zJXGi4ZbikG+dk3WSaMPqoCkDA8Bc0WpOBo EpciITHa+WYGaIH58hA2ukCv/6dSS1nW1p+9i2Z8iJ033S03yxO04Pq0uGdEXakgLDld vYR5htnsm40m3w3cvBP5q1AjbICxGdWRxaHa4CbZeGT+ut4wO81Jyhqpo7uYHNShA3eG v3YrqaJx4pOhraxLS9T/MwjPYAYKyvFpM4nKMo7JBzxkHEcmYDVZX3I3JFf7aFrx7Qg0 3BVA== X-Gm-Message-State: AFqh2koeCXzgZhVH208D+5ijmBUD2/FbPdNgdku6Z+p6sjDpwxO4jjA9 NAAkpfYClvgbQHGNy8g+eGM= X-Google-Smtp-Source: AMrXdXuA1B0/qpCv4A2WttN0GVH9WzblPHIYwI2BaH5xBk6/ZVpg5KMsxHWj6EFIjSKesjffYF9jVg== X-Received: by 2002:a05:6402:4486:b0:48f:a9a2:29f4 with SMTP id er6-20020a056402448600b0048fa9a229f4mr12527694edb.1.1674152923429; Thu, 19 Jan 2023 10:28:43 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m2-20020a509302000000b0046892e493dcsm16188924eda.26.2023.01.19.10.28.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Jan 2023 10:28:43 -0800 (PST) Content-Language: en-US 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:253723 Archived-At: 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’ve 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’ll report back once I add it. > > I wrote that function. But I didn’t 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. > Could you try the latest commit and see if the fast mode still switches > on when it shouldn’t? 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.