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: Mon, 30 Jan 2023 01:07:10 +0200 Message-ID: <0e552ada-081f-ad90-19c2-645a64ef50ac@yandex.ru> References: <867cxv3dnn.fsf@mail.linkov.net> <90D8581D-C543-43EE-8BEB-51B5AFBCBAEE@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="943"; 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 Mon Jan 30 00:08:14 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 1pMGmS-000AdM-P5 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Jan 2023 00:08:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMGmK-00080O-FE; Sun, 29 Jan 2023 18:08: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 1pMGmI-00080F-GQ for bug-gnu-emacs@gnu.org; Sun, 29 Jan 2023 18:08: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 1pMGmI-00043N-8E for bug-gnu-emacs@gnu.org; Sun, 29 Jan 2023 18:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pMGmI-0005Nu-0M for bug-gnu-emacs@gnu.org; Sun, 29 Jan 2023 18:08: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, 29 Jan 2023 23:08: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.167503364220651 (code B ref 60691); Sun, 29 Jan 2023 23:08:01 +0000 Original-Received: (at 60691) by debbugs.gnu.org; 29 Jan 2023 23:07:22 +0000 Original-Received: from localhost ([127.0.0.1]:45563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pMGld-0005N0-Fv for submit@debbugs.gnu.org; Sun, 29 Jan 2023 18:07:21 -0500 Original-Received: from mail-ed1-f48.google.com ([209.85.208.48]:33711) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pMGlb-0005Mn-Kt for 60691@debbugs.gnu.org; Sun, 29 Jan 2023 18:07:20 -0500 Original-Received: by mail-ed1-f48.google.com with SMTP id x7so6138561edr.0 for <60691@debbugs.gnu.org>; Sun, 29 Jan 2023 15:07:19 -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=tVI5ZqFpxXK1//xIYEcRpZrjtZawj0OZt0MXOlQlPZM=; b=TsZDjH/dneM+L5NiOgo9fnVB1eqCWjPxqObcNtDcM5honPtwcOt2CQyR/0nG/oFcYS 8VQbqMZIKEgF2VB0AYOBsC2ekhMfrfpOwLxYdwALQF86dT17eA/OKeGI27fTrce3YLfR 34jw6BLtDkNbX/SRM8g/aswZ/6ildq0r1YjhDfDLGmHN0EynUBVAEXSA9VuW4Evfntgy ZGF8PLIlsQnbnvX1ZezvxNU3C1FPN5UcJqY8hsTrT/u+1/YWnDvn2+4QREY/k8gc6PsS 2ZAWkyIxYIbofRaF+Jwabf4ZKch2h/H/kij+qrQQGoYevROx551tEY8WIJNSVrg0Qt2Y XiBQ== 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=tVI5ZqFpxXK1//xIYEcRpZrjtZawj0OZt0MXOlQlPZM=; b=11OGInyf5YGrxm3FDflRkvYH38dgGygWqGKqFcyBirO4qYM8gQzDlWzIQxwcl3vKrP RPygQUoixmzu8tTVnUsI7ySoQoXu05MZSvqaXYTFzV+b2x8qVbh3e8a5mAvn9GA9PX7a x5t8p5Bd9CRnu7HT9tDAN5vvovexR8B1qtxpRgwdaTTDrqdUPsJKMdt826EqziXZtIV2 8bb8V7azy1o2SBiorrY1jJ+g+MTq8uL4O+W/aNo8JzQ6x0NEEualjqxbc8dV8O3wMoei 29K2z66vbb+j0OkOkyBUqL/3Xs/eBD1yxWUEHMo4jNdJGR8v2kMo8rXvGDyuZLONxsph q8Jg== X-Gm-Message-State: AFqh2krTpCSsObtOZ6JWLn6C9pP8TwiW3XaTUwzmwhTDlhbuaxm9gEjV OOXKAIFLHi7xZCnC9oxXYpE= X-Google-Smtp-Source: AMrXdXsG/eJcH/M21fyFDVFbzWCYGpAJpyMiQq1S7lds7QLSKAVa36gdzIu8j0nxHU27Ztj8Z6Pnjw== X-Received: by 2002:a05:6402:2b92:b0:45a:7d2:9b35 with SMTP id fj18-20020a0564022b9200b0045a07d29b35mr50810466edb.0.1675033633640; Sun, 29 Jan 2023 15:07:13 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id y8-20020a056402134800b004610899742asm5869860edw.13.2023.01.29.15.07.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 Jan 2023 15:07:12 -0800 (PST) Content-Language: en-US In-Reply-To: <90D8581D-C543-43EE-8BEB-51B5AFBCBAEE@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:254384 Archived-At: Hi Yuan, On 29/01/2023 10:25, Yuan Fu wrote: >>>> 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. > > 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. Thank you, it seems to work just fine in my scenario. And treesit-subtree-stat makes sense. I have a few more questions about the current strategy, though. IIUC, we only do the treesit--font-lock-fast-mode test once in treesit-font-lock-fontify-region, and then use the detected value for the whole later life of the buffer. Is that right? What if the buffer didn't originally have the problematic error nodes we are guarding from, and then later the user wrote enough code to have at least one of them? If they didn't close Emacs, or revert the buffer, our logic still wouldn't use the "fast node", would it? Or vice versa: if the buffer started out with error nodes, and consequently, "fast mode", but then the user has edited it so that those error nodes disappeared, shouldn't the buffer stop using the "fast mode"? From my measurements, in ruby-mode, at least treesit-subtree-stat is 20-40x faster than refontifying the whole buffer. So one possible strategy would be to repeat the test every time. I'm not sure it's fast enough in the "problem" buffers, though, and I don't have any to test. In those I did test, though, it takes ~1 ms. But we could repeat the test only once every couple of seconds and/or after the buffer has changed again. That would hopefully make it a non-bottleneck in all cases.