From: Dmitry Gutov <dgutov@yandex.ru>
To: Yuan Fu <casouri@gmail.com>
Cc: 60691@debbugs.gnu.org, juri@linkov.net
Subject: bug#60691: 29.0.60; Slow tree-sitter font-lock in ruby-ts-mode
Date: Mon, 30 Jan 2023 01:07:10 +0200 [thread overview]
Message-ID: <0e552ada-081f-ad90-19c2-645a64ef50ac@yandex.ru> (raw)
In-Reply-To: <90D8581D-C543-43EE-8BEB-51B5AFBCBAEE@gmail.com>
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.
next prev parent reply other threads:[~2023-01-29 23:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 17:16 bug#60691: 29.0.60; Slow tree-sitter font-lock in ruby-ts-mode Juri Linkov
2023-01-09 22:33 ` Dmitry Gutov
2023-01-10 8:10 ` Juri Linkov
2023-01-10 14:10 ` Dmitry Gutov
2023-01-10 17:50 ` Juri Linkov
2023-01-11 12:12 ` Dmitry Gutov
2023-01-11 12:12 ` Dmitry Gutov
2023-01-12 21:58 ` Yuan Fu
2023-01-12 23:40 ` Dmitry Gutov
2023-01-13 7:57 ` Eli Zaretskii
2023-01-13 9:15 ` Yuan Fu
2023-01-13 11:51 ` Eli Zaretskii
2023-01-14 3:48 ` Yuan Fu
2023-01-14 7:29 ` Eli Zaretskii
2023-01-14 7:51 ` Yuan Fu
2023-01-14 8:01 ` Eli Zaretskii
2023-01-14 8:46 ` Andreas Schwab
2023-01-14 23:03 ` Yuan Fu
2023-01-18 6:50 ` Yuan Fu
2023-01-19 18:28 ` Dmitry Gutov
2023-01-20 22:24 ` Yuan Fu
2023-01-22 2:01 ` Dmitry Gutov
2023-01-29 8:25 ` Yuan Fu
2023-01-29 23:07 ` Dmitry Gutov [this message]
2023-01-29 23:23 ` Yuan Fu
2023-01-30 0:15 ` Dmitry Gutov
2023-02-01 5:26 ` Yuan Fu
2023-02-01 15:11 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0e552ada-081f-ad90-19c2-645a64ef50ac@yandex.ru \
--to=dgutov@yandex.ru \
--cc=60691@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).