Clojurians Log v2

a short answer is that i don't have measurements. i intend to figure out how to do that. a silghtly more detailed answer is, even if i do measure what i've got now, it's not doing as much as calva does so it may not be a very good comparison. there are some reasons why it's not doing more highlighting, but that takes a bit more explaining which i hope to do subsequently.

ah, i think i misread what you wrote. so if i understand correctly, you tested a situation where there is comment highlighting and rainbow parens. what i currently have is code that highlights: 1. parens and square brackets (no curly brackets) 2. keywords 3. scanning for def-like list forms and coloring the first symbol after the located def-like symbol 4. changing the color of the call symbol in an anonymous function (used to all try to do this for other things that look like function calls, but am not currently) my initial measurements suggest that processing the entire tree-sitter tree to gather the required info for coloring (including creating the Range objects) takes about half a second for clojure's core.clj. (this time does not include the creation of the tree itself.) the actual calls to .setDecoration total to about 60-70 ms. for the highlighting i haven't implemented using the query api -- i'm traversing the tree using a sequence returned by tree-seq.

That is similar to what I get. My testing instigates that most of the time is spent creating the Range objects. Creating a Range also seems to be more expensive in large files.

those are very interesting points. thanks for sharing. i have a little extra info regarding tree-sitter performance. the numbers i mentioned before about 20ms for clojure.core are from running the tree-sitter cli. i think that's written in rust, and i'm guessing the performance is essentially as fast as one is going to get. in vscode, i'm using the wasm bindings which as we've noted are supposedly slower (https://github.com/tree-sitter/tree-sitter/tree/master/lib/binding_web#running-wasm-in-nodejs). i just checked this brielfy and the numbers i'm getting range from 45ms to 60ms (though often under 50ms).

perhaps it's worth trying the non-wasm bindings in the editor at some point.

50ms is nice!

I think that for Calva it won't come down to a performance issue. The Calva parser is pretty fast. It is rather about using a community parser implementation that several projects share.

Also I have tried to figure out how much time Calva's rainbow painting spends on the task of gathering the info from the TokenCursor vs creating vscode Position and Range objects. For Clojure core.clj it is about 50/50. For more normal files it is about 80/20 (and 5ms in total anyway). The actual traversing of the TokenCursor takes almost no time, as I guess it is with the tree-seq you have. It is to actually do anything with the info that takes time, and then the ”AST” type doesn't matter performance wise. (This is my hunch.)

very interesting. may be i will try to figure out something similar for this end -- i wonder if there aren't some profiling tools that are usable via the devtools console...