unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 60691@debbugs.gnu.org
Subject: bug#60691: 29.0.60; Slow tree-sitter font-lock in ruby-ts-mode
Date: Tue, 10 Jan 2023 10:10:53 +0200	[thread overview]
Message-ID: <86leman71u.fsf@mail.linkov.net> (raw)
In-Reply-To: <51ee2f6f-6e1d-eccd-f536-461d916cc94d@yandex.ru> (Dmitry Gutov's message of "Tue, 10 Jan 2023 00:33:12 +0200")

>> After more rules were added recently to ruby-ts--font-lock-settings,
>> font-lock became slow even on very small files.  Some measurements:
>
> If you saw a particular commit that made things slower, did you try
> reverting it? What was the performance after?

No particular commit, just adding more rules degrades performance
gradually.

>> M-: (benchmark-run 1000 (progn (font-lock-mode -1) (font-lock-mode 1) (font-lock-ensure)))
>> M-x ruby-mode
>> (1.3564674989999999 0 0.0)
>> M-x ruby-ts-mode
>> (8.349582391999999 2 6.489918534000001)
>
> I have tried this scenario (which, to be frank, is pretty artificial, given
> that fontification is usually performed in chunks, not over the whole
> buffer).
>
> Perhaps the results depend on a particular file. The ones I have tried
> (ruby.rb and ruby-after-operator-indent.rb) show only 2x difference (or
> less). The difference was in favor of ruby-mode, but given the difference
> in approaches I wouldn't be surprised if ruby-ts-mode incurs a fixed
> overhead somewhere.

On test/lisp/progmodes/ruby-mode-resources/ruby.rb I see these numbers:

ruby-mode
(8.701560543000001 95 1.045961102)

ruby-ts-mode
(34.653148898000005 1464 16.904981779)

>> This is not a problem when files are visited infrequently, but
>> becomes a problem for diff-syntax fontification that wants to
>> highlight simultaneously many files from git logs.
>> So a temporary measure would be not to enable ruby-ts-mode
>> in internal buffers:
>
> Is it common to try to highlight 1000 or even 100 files in one diff?

100 is rare, but tens is pretty common, so this problem affects
only this specific case.

>> (add-hook 'find-file-hook
>>            (lambda ()
>>              (when (and (eq major-mode 'ruby-mode)
>>                         ;; Only when not internal as from diff-syntax
>>                         (not (string-prefix-p " " (buffer-name))))
>>                (ruby-ts-mode))))
>
> Have you tried similar tests with other -ts- modes? Ones with complex
> font-lock rules in particular.

I tried with c-ts-mode, and it's very fast.

> I've tried commenting out different rules in ruby-ts--font-lock-settings,
> but none of them seem to have particularly outsides impact. Performance
> seems, roughly, inversely proportional to the number of separate
> "features".

Indeed, this is what I see - no particular rule, only their number
affects performance.

> And if all ts modes turn out to have this problem, perhaps the place to
> improve this is inside some common code.

I noticed that while most library files are small, e.g.
libtree-sitter-c.so is 401,528 bytes,
libtree-sitter-ruby.so is 2,130,616 bytes
that means that it has more complex logic
that might explain its performance.

In this case, when nothing could be done to improve performance,
please close this request.





  reply	other threads:[~2023-01-10  8:10 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 [this message]
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
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=86leman71u.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=60691@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    /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).