From: Dmitry Gutov <dgutov@yandex.ru>
To: Yuan Fu <casouri@gmail.com>
Cc: 61285@debbugs.gnu.org
Subject: bug#61285: (Sometimes very) slow font-lock after %w in ruby-ts-mode
Date: Mon, 6 Feb 2023 03:03:06 +0200 [thread overview]
Message-ID: <06cc9ece-ac9a-e9e7-df9d-0b10978379a4@yandex.ru> (raw)
In-Reply-To: <2C6F83F0-DD84-4549-9D91-3D820188674D@gmail.com>
On 06/02/2023 02:08, Yuan Fu wrote:
> Interesting. Perhaps it has to do with how tree-sitter implements the
> "incremental" part of the parser? But the profile doesn’t look like it’s
> spending time parsing,
According to my tests, what gets slower are the treesit-query-capture
calls. And I mean all of them (for every element in
treesit-font-lock-settings), not just the first one, which I imagine
would be the case if tree-sitter needed to finish parsing the current
buffer contents.
If I just wrap the treesit-query-capture calls inside
treesit-font-lock-fontify-region in benchmark-progn, with %w inside the
'if' block the queries are an order of a magnitude faster than with it
at top level.
E.g. in the ruby.rb example, the former look like
...
Elapsed time: 0.001648s
Elapsed time: 0.001498s
Elapsed time: 0.001211s
Elapsed time: 0.000949s
Elapsed time: 0.000950s
...
and the latter are like
...
Elapsed time: 0.006567s
Elapsed time: 0.006583s
Elapsed time: 0.007072s
Elapsed time: 0.006867s
Elapsed time: 0.006575s
Elapsed time: 0.006608s
...
Multiply that by 19 (the number of rules), and we get the perceived delay.
And for associations.rb, the query times are 0.004322s vs 1.083029s.
> I need to look at what does
> ts_tree_cursor_current_status actually do (maybe it’s used in parsing?)
// Private - Get various facts about the current node that are needed
// when executing tree queries.
void ts_tree_cursor_current_status(
https://github.com/tree-sitter/tree-sitter/blob/84c1c6a271cd0ab742ce0f46cd3576a6f6bf5b8c/lib/src/tree_cursor.c#L284
I see it is called by ts_query_cursor__advance, which is in turn called
by ts_query_cursor_next_match. And ts_query_cursor_next_capture, which
we don't seem to be using.
Here's an existing report on its tracker which might be relevant:
https://github.com/tree-sitter/tree-sitter/issues/1972
Similar perf report, though not exactly the same.
next prev parent reply other threads:[~2023-02-06 1:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-05 0:39 bug#61285: (Sometimes very) slow font-lock after %w in ruby-ts-mode Dmitry Gutov
2023-02-06 0:08 ` Yuan Fu
2023-02-06 1:03 ` Dmitry Gutov [this message]
2023-02-06 3:20 ` Dmitry Gutov
2023-02-21 3:12 ` Dmitry Gutov
2023-02-21 8:14 ` Yuan Fu
2023-02-21 9:53 ` Dmitry Gutov
2023-02-27 0:37 ` Yuan Fu
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=06cc9ece-ac9a-e9e7-df9d-0b10978379a4@yandex.ru \
--to=dgutov@yandex.ru \
--cc=61285@debbugs.gnu.org \
--cc=casouri@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.