Construct Tree Sitter queries only once

[oyarsa]

This is the speed-up mentioned in #14 (comment). I figured it was easy enough to just do it. I can post more rigorous results, but here's why I did this:

I was benchmarking the tool to see if filtering afterwards made any difference. I noticed that when parsing multiple files, the same query was being re-created, and it wasn't free. My test case was taking https://github.com/rust-lang/rust, adding tags to the comments with sed [1], and running anot . in the repository root. Before this PR, it took ~50s. Now, it takes ~12s. It doesn't make any difference if it runs on a single file.

[1] git ls-files '*.rs' | xargs sed -i '/[^\/]\/\/ /s/\/\/ /\/\/ @tag: /'

[rorybyrne]

50s -> 12s is a big improvement, thank you. But even 12s still seems quite long. How much faster is ripgrep?

[rorybyrne]

Nvm I'll just run it and see myself

[rorybyrne]

rg "println" --type rust 0.23s user 1.31s system 436% cpu 0.353 total

Running at the base of rust-lang/rust.

Wow!

[oyarsa]

ripgrep takes 1s and regular grep -r 2.5s. The latter is likely because it doesn't ignore gitignore. Does anot do that?

[rorybyrne]

No we just naively walk the directory at the moment. Should open some issues for .gitignore and possibly filetype filtering.

[oyarsa]

Regarding why it's so much slower, it's because tree-sitter parsing is slow. Here's a flamegraph of the latest version:

Since it's CPU-bound, we might get some speed-up from parallelising this. It should be straightforward with rayon.

Maybe we can figure out a way to exclude files without annotations before they're parsed. Straight regex testing for //.*@.*: would be a lot faster. That might work well in real codebases, but it wouldn't change the benchmark I'm running.

Edit: it seems that GitHub removes the interactive parts of the flamegraph. The stuff on the left that you can't read is input::read_file with only 8% of the samples.

[rorybyrne]

I was wondering if rg can do this, and it seems it can. With a bit of coaxing, Claude was able to come up with this equivalent rg command:

❯ rg -n --json "@(\w+):\s*(.+)" tests | jq -c 'select(.type == "match") | {
 kind: (.data.submatches[0].match.text | capture("@(?<tag>\\w+):.*").tag),
 content: (.data.submatches[0].match.text | capture("@\\w+:\\s*(?<content>.+)").content),
 location: {
   file: .data.path.text,
   line: .data.line_number,
   inline: (
     .data.lines.text |
     (test("^\\s*//") or test("^\\s*#")) | not
   )
 }
}'

{"kind":"note","content":"this experiment will be re-written later","location":{"file":"tests/data/test.py","line":2,"inline":false}}
{"kind":"hypothesis","content":"5 is better than 4","location":{"file":"tests/data/test.py","line":5,"inline":true}}
{"kind":"todo","content":"Add initialization","location":{"file":"tests/data/test.js","line":3,"inline":true}}
{"kind":"bug","content":"Sometimes fails on Safari","location":{"file":"tests/data/test.js","line":7,"inline":false}}
{"kind":"todo","content":"Add more fields","location":{"file":"tests/data/test.rs","line":2,"inline":false}}
{"kind":"fixme","content":"This needs better error handling","location":{"file":"tests/data/test.rs","line":9,"inline":true}}

Firstly, this is one of those moments where LLMs amaze me. That took <5 minutes...

Secondly, it makes me question what value our tool adds. Tree sitter integration, potentially? Some other yet-unknown feature we could build?