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: Sun, 22 Jan 2023 04:01:38 +0200 Message-ID: <3308a010-b1aa-8c99-887e-7dc1e0e94709@yandex.ru> References: <867cxv3dnn.fsf@mail.linkov.net> <4b75a1e5-ace9-2312-54f7-c1de9c798d9c@yandex.ru> <90D70081-4A27-4219-93C3-240D35F29711@gmail.com> 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="8708"; 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 Sun Jan 22 03:02:24 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 1pJPge-00022A-Cr for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 22 Jan 2023 03:02:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJPgK-0003NI-Kn; Sat, 21 Jan 2023 21:02:04 -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 1pJPgI-0003LT-G1 for bug-gnu-emacs@gnu.org; Sat, 21 Jan 2023 21:02:02 -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 1pJPgI-0003Jq-7F for bug-gnu-emacs@gnu.org; Sat, 21 Jan 2023 21:02:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pJPgI-0002S8-2T for bug-gnu-emacs@gnu.org; Sat, 21 Jan 2023 21:02:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Jan 2023 02:02: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.16743529099408 (code B ref 60691); Sun, 22 Jan 2023 02:02:02 +0000 Original-Received: (at 60691) by debbugs.gnu.org; 22 Jan 2023 02:01:49 +0000 Original-Received: from localhost ([127.0.0.1]:50143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pJPg5-0002Rg-0q for submit@debbugs.gnu.org; Sat, 21 Jan 2023 21:01:49 -0500 Original-Received: from mail-ed1-f46.google.com ([209.85.208.46]:38411) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pJPg2-0002RQ-N0 for 60691@debbugs.gnu.org; Sat, 21 Jan 2023 21:01:47 -0500 Original-Received: by mail-ed1-f46.google.com with SMTP id w14so10869310edi.5 for <60691@debbugs.gnu.org>; Sat, 21 Jan 2023 18:01:46 -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=mBPwKCs9yt08/M0LVqu84LIsYbWS6LrGx9QbglXHzQA=; b=YiXM6kgthn5MVQFiIrkCnITsHiD7v94AcqhclpuzHbJroMnnHdnKx30hBcBuxdc/A0 OVfrik9HmXMr55aGs4kVp/qtyCDThtX99GNrJUN8zpWjPHJ3h+ly1m5iBy7buFyFCpvx n0iPaArtOCDUzm7dYqKZ0EcnowKI8RuwLYprCTHEGOL2FIKXwOtvOc+M/2cGDcQCB+IL jmWN1+nrBSTJQZiCCw1xS76kENGf7wkWqrR6nOfW4kGjefqzBqB2KlAnzj13KexUCk+5 tELJTAHXbM3xUibFSAqmxcsBNPvX7YY32w/KheIbAMCy6y6PjQ1ySOdZ6LKVwBtza+vU n0ww== 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=mBPwKCs9yt08/M0LVqu84LIsYbWS6LrGx9QbglXHzQA=; b=U1qXMpR4C25HVcAt6Hgsi56G7s5u7Xs7aCVM3gTT81/1q9Vt/zkoEQcTNfs9ee8nV4 TdVO6iTFZ5/mU/0rmvxMcDYK3AK/vg53QKyLXNKOX0YPbni1KTc7H3w3JWcjgJl21nWj v/SPxIPBSdpRcz7ijgUFYzpm2QueOQMvpWuxVcWyGH51IKrMGyEJwY1sJnAO/Bbi2eFZ kIqlDy1M8T+B/k5O5pdhLXh6+/4SBK8bgNWqlACT43fKtGYQItEs+Qpp1I1MRKyuFMeb WobYKcj8JN7Y4llIflsSNdieE0KCUMA/eGO5FEAKZE3/WjI22Ad9HAEH6dWjUsPKSxNX mLFw== X-Gm-Message-State: AFqh2kqZimWqlZxgk/009mP1ie9JvNtoVP4NGyAKhM3gpu7S4Vop/Dpe hFqV91Nc1MmwVJAze8bn1Bc= X-Google-Smtp-Source: AMrXdXtdo9bFIDxU2Uts2RJne77nstH2gXciqcavWP0LX8RHf5D9Wrn0Rx9oAR6xYm/RylgVMYK+Hw== X-Received: by 2002:a05:6402:2499:b0:499:1ed2:645d with SMTP id q25-20020a056402249900b004991ed2645dmr21912553eda.17.1674352900719; Sat, 21 Jan 2023 18:01:40 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id f6-20020a056402150600b0049622a61f8fsm19573434edw.30.2023.01.21.18.01.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 Jan 2023 18:01:40 -0800 (PST) Content-Language: en-US In-Reply-To: <90D70081-4A27-4219-93C3-240D35F29711@gmail.com> 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:253896 Archived-At: On 21/01/2023 00:24, Yuan Fu wrote: > > >> 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’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. > > The condition is “query is (consistently) slow”, that’s 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’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. > > I was hoping that the scenario only happen once, oh well :-) I’ll change the decision based on analyzing the tree’s dimension: too deep or too wide activates the fast mode. Let’s see how it works. Thank you, let me know when it's time to test again.