From: Dmitry Gutov <dmitry@gutov.dev>
To: Yuan Fu <casouri@gmail.com>, Vincenzo Pupillo <v.pupillo@gmail.com>
Cc: "Ergus via Emacs development discussions." <emacs-devel@gnu.org>,
Eli Zaretskii <eliz@gnu.org>
Subject: Re: treesitter local parser: huge slowdown and memory usage in a long file
Date: Tue, 13 Feb 2024 02:50:20 +0200 [thread overview]
Message-ID: <acd2994d-ca5f-4747-9875-4d362697108f@gutov.dev> (raw)
In-Reply-To: <93F7DE13-0EC7-4A17-89B1-E07C99C6347B@gmail.com>
On 12/02/2024 06:16, Yuan Fu wrote:
> Thanks, the culprit is the call to treesit-update-ranges in
> treesit--pre-redisplay, where we don’t pass it any specific range, so it
> updates the range for the whole buffer. Eli, is there any way to get a
> rough estimate the range that redisplay is refreshing? Do you think
> something like this would work?
If we don't update the ranges outside of some interval surrounding the
window, what does that mean for correctness?
Perhaps the mode has a syntax-propertize-function which behaves
differently (as it should) depending on the language at point. Or
different ranges have different syntax tables, something like that.
If the ranges, after some edit (perhaps a programmatic one, performed
far from the visible area), are kept not update somewhere around the
beginning of the buffer, do we not risk confusing the syntax-ppss
parser, for example?
Come to think of it, take treesit-indent: it only updates the ranges for
the current line. But the line's indentation usually depends on the
previous buffer positions, doesn't it?
next prev parent reply other threads:[~2024-02-13 0:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-11 21:53 treesitter local parser: huge slowdown and memory usage in a long file Vincenzo Pupillo
2024-02-12 4:16 ` Yuan Fu
2024-02-12 14:09 ` Eli Zaretskii
2024-02-13 8:15 ` Yuan Fu
2024-02-13 9:39 ` Vincenzo Pupillo
2024-02-13 12:59 ` Eli Zaretskii
2024-02-13 0:50 ` Dmitry Gutov [this message]
2024-02-13 8:08 ` Yuan Fu
2024-02-18 3:37 ` Dmitry Gutov
2024-02-19 5:53 ` Yuan Fu
2024-03-21 6:39 ` Yuan Fu
-- strict thread matches above, loose matches on Subject: below --
2024-04-20 2:18 Yuan Fu
2024-04-20 19:14 ` Vincenzo Pupillo
2024-04-23 5:09 ` Yuan Fu
2024-05-06 2:04 ` Dmitry Gutov
2024-05-09 0:16 ` Yuan Fu
2024-05-12 23:44 ` Dmitry Gutov
2024-05-22 5:51 ` Yuan Fu
2024-05-22 23:42 ` Dmitry Gutov
2024-05-27 22:03 ` Yuan Fu
2024-05-27 22:24 ` Dmitry Gutov
2024-06-04 4:53 ` Yuan Fu
2024-06-04 8:19 ` Vincenzo Pupillo
2024-06-04 15:01 ` Eli Zaretskii
2024-06-04 20:44 ` Vincenzo Pupillo
2024-06-06 23:59 ` Dmitry Gutov
2024-06-07 0:13 ` Dmitry Gutov
2024-06-11 16:36 ` Yuan Fu
2024-05-26 4:23 ` Stefan Monnier via Emacs development discussions.
2024-05-27 22:05 ` Yuan Fu
2024-05-27 22:34 ` Stefan Monnier
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=acd2994d-ca5f-4747-9875-4d362697108f@gutov.dev \
--to=dmitry@gutov.dev \
--cc=casouri@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=v.pupillo@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.