bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60691: 29.0.60; Slow tree-sitter font-lock in ruby-ts-mode


From: Dmitry Gutov
Subject: bug#60691: 29.0.60; Slow tree-sitter font-lock in ruby-ts-mode
Date: Thu, 19 Jan 2023 20:28:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]