little fixes in docs

BENCHMARKING.md

@@ -1,10 +1,10 @@
 # Benchmarking
 
-I'm benchmarking on two repos (see `script/bench.sh`):
+I'm benchmarking on two repos (see `script/bench.sh` for the one you can run yourself):
 
 | Target                                                                              | Time              |
 |-------------------------------------------------------------------------------------|-------------------|
-| (elm-spa-example)[https://github.com/rtfeldman/elm-spa-example] (224kb of Elm code) | 10.6 ms ± 0.6 ms  |
+| [elm-spa-example](https://github.com/rtfeldman/elm-spa-example) (224kb of Elm code) | 10.6 ms ± 0.6 ms  |
 | my main work repo (12mb of Elm code)                                                | 196.7 ms ± 5.4 ms |
 
 The standard to meet or exceed here is the tool this is replacing, which runs in `1.210 s ± 0.016 s` on the work repo.
@@ -15,6 +15,8 @@ I doubt there are many repos in the world as big as the one I'm working with, so
 
 ## Things I've tried
 
+In reverse chronological order:
+
 ### November 19: Cutting off matches early
 
 The Elm compiler requires imports to be at the top of the file.

README.md

@@ -98,14 +98,19 @@ Finally, in our external style guide we version modules like `Nri.Ui.Doodad.V1`
 ### Why is this written in Rust instead of `X`?
 
 I wanted to learn Rust, and I started off by using `tree-sitter`, which has excellent Rust bindings.
-That version of the tool turned out to be pretty slow, so I dropped it in favor of regular expressions.
+That version of the tool turned out to be pretty slow, so I dropped `tree-sitter` in favor of regular expressions.
 Now it's pretty quick!
 
-### Is this fast?
+### How quick is it?
 
-It's pretty fast.
-It could probably go faster, but I think we've reached the point of diminishing returns here.
-See [BENCHMARKING.md](BENCHMARKING.md).
+It runs on elm-spa-example (224kb of Elm code) in about 10ms, and my main work repo (12mb of Elm code) in about 200ms.
+Most projects fall somewhere in between there, so I'm confident in saying that you probably won't get bored while waiting for this to run, and it won't add an unmanageable amount of overhead to your CI runs.
+
+That said, wec could probably go faster; in particular, the tool does a lot more allocations than it strictly needs to.
+But... 10—200ms is well within the acceptable times for a development tool, so I think it's about fast enough.
+See [BENCHMARKING.md](BENCHMARKING.md) for more and how it got to this speed.
+
+If you're an experienced Rust programmer and know about easy further wins here, please [get in touch](mailto:brian@brianthicks.com).
 
 ## Contributing