Will Treesitter ever be stable on big files?

1. neovim

   1 1,464 100,193 10.0 Vim Script

   Vim-fork focused on extensibility and usability

   

   Injection tree is not incremental. This is a direct cause of 1, and is the biggest performance issue caused by TS in nvim now. The injection trees will be rebuilt and reparsed at every buffer change. Usually this will incredibly prolong the screen drawing time and block editing for a long time at every keystroke on large file, causing editor unusable.

2. SaaSHub

   www.saashub.com featured

   SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

   

3. nvim-treesitter

   2 319 13,622 9.6 Tree-sitter Query

   Discontinued Nvim Treesitter configurations and abstraction layer

   

   Bloated injection queries ships with nvim-treesitter. As a half-official TS support plugin in nvim, all-in-one also means bloating for normal users. See injection query for javascript in nvim-treesitter for example. Usually users are not in high demand of them in normal programming language (unlike markdown), but they will pay the extreme high performance cost for this feature.

4. tree-sitter

   3 77 25,709 9.8 Rust

   An incremental parsing system for programming tools

   

   The following discussion here. TS query cannot be incremental, that is why I regard it as design fault.

5. helix

   4 484 44,803 9.8 Rust

   A post-modern modal text editor.

   

   True, However (as someone who doesn't have any experience with tree-sitter) the commits adding incremental injection parsing look quite obtruse: https://github.com/helix-editor/helix/compare/6728e44..4080341

6. syntect

   5 7 2,352 7.8 Rust

   Rust library for syntax highlighting using Sublime Text syntax definitions.

   

   I wonder if a plugin integrating syntect would be possible.

7. tree-sitter-comment

   6 7 168 4.3 C

   Tree-sitter grammar for comment tags like TODO, FIXME(user).

   

   you mean this one? https://github.com/stsewd/tree-sitter-comment

8. tracy

   7 75 16,050 9.9 C++

   Frame profiler

   

   I also found that using https://github.com/wolfpld/tracy with tree-sitter functions marked in Neovim that some individual queries and parse operation would have significant perf impact while other do not and that there are some parsers who tend to not really support incremental parsing but often need to throw away from cursor position until file end on certain character. We would need more infrastructure and built-in profiling to detect problems in certain languages earlier.

Suggest a related project