Reading the article is like climbing a load-bearing wall to quote their last phrase.
I've seen "load bearing" so many times in AI now I can't remember whether we always used "load bearing wall" to refer to a structural interior wall, or whether it's a recent AI-ism.
How AST-grep Rewrote Tree-sitter in Rust and Made It 30% Faster
11–18 of 18 posts
Re: How AST-grep Rewrote Tree-sitter in Rust and Made It 30% Faster
#12Re: How AST-grep Rewrote Tree-sitter in Rust and Made It 30% Faster
#13Re: How AST-grep Rewrote Tree-sitter in Rust and Made It 30% Faster
#14Re: How AST-grep Rewrote Tree-sitter in Rust and Made It 30% Faster
#15Earlier quoted context omitted.
I've seen "load bearing" so many times in AI now I can't remember whether we always used "load bearing wall" to refer to a structural interior wall, or whether it's a recent AI-ism.
Jerry, these are load-bearing walls! [1] [1]: https://youtu.be/IbVmxkVC5kc?t=83
https://amphetamem.es/meme/?id=the-simpsons_08_08_248&text=I...
Re: How AST-grep Rewrote Tree-sitter in Rust and Made It 30% Faster
#16> incremental old-tree reuse were removed Maybe I am missing what they meant here, but isn’t the entire point of tree-sitter that you can reuse old trees to make edit updates faster? It is seems quite probable that all the performance gains came from optimising for fixed files with no error recovery, at the cost of how ts is actually used.
No, not for ast-grep.
Re: How AST-grep Rewrote Tree-sitter in Rust and Made It 30% Faster
#17Re: How AST-grep Rewrote Tree-sitter in Rust and Made It 30% Faster
#18I really don't like this. Don't post your AI-generated articles here. https://www.pangram.com/history/fce67fb4-4f6a-4eb4-a323-5048...
It seems like a lot of the speedup comes from using an arena, using realloc with offsets rather than raw pointers and some change to the graph that enabled this (though I don't want to re-read it to confirm).