| The scale of the improvement is up to 100x. For me it has been on the edge between “acceptable” and “very bad”. I have the impression that most modes are using treesit-query-capture with compiled queries for performance-sensitive stuff (font lock), which is fast, and hasn’t changed. So those shouldn’t be affected.
But any tree-sitter modes developed over the next few years to respect more “containing context” (structural editing, navigation, smarter context highlighting and folding, etc.) will I bet first reach for treesit-node-parent and its friends treesit-parent-while/until, as I did. For example, I believe combobulate[1] is using these frequently (Mickey copied here). These functions are up to 100x slower than necessary on long but still reasonable (10k line) files.
Is there a test harness somewhere that exercises treesit commands in large buffers of various different languages? Perhaps a test could be added to “navigate up several generations” from random locations in the buffer and confirm the same nodes are reached.
On Aug 31, 2023, at 8:51 AM, Eli Zaretskii <eliz@gnu.org> wrote:
Date: Thu, 31 Aug 2023 14:04:39 +0300
Cc: jdtsmith@gmail.com, emacs-devel@gnu.org
From: Dmitry Gutov <dmitry@gutov.dev>
On 31/08/2023 09:03, Eli Zaretskii wrote:
Thanks, but why emacs-29? Is this a bugfix?
Depending on the POV, O(N^2) performance for certain buffer interactions
can be considered a bug.
Performance improvement is an enhancement. Unless the performance is very bad, I don't think its place is on the release branch, especially after the major release. Stefan, WDYT?
|