levenshtein-distance-benchmarks

It looks like you got that from this PR: https://github.com/christianscott/levenshtein-distance-bench... That PR does not make the benchmark loads "equivalent." Please look at the diff. That PR adds parallelism to the Rust program. The Go program does not have parallelism.

While Go may be faster somewhere, that post was not a good comparison. See the discussion around it and the patches made by the community and the final results. See the individual benchmarks: https://github.com/christianscott/levenshtein-distance-bench...

A few folks have commented that there were logic errors in the Go version. Specifically that len("föö") = 5 should instead have returned len("föö") = 3 I submitted a pull request, https://github.com/christianscott/levenshtein-distance-bench..., that fixes these issues in the Go implementation. Interestingly enough, when I re-ran the benchmark, the Go version is roughly 19% faster than it was previously: old: 1.747889s new: 1.409262s (-19.3%)

It's cheap, but not _that_ cheap. It shouldn't be as cheap as just iterating over a sequence of 32-bit integers. But yes, I did benchmark this, even after reusing allocations, and I can't tell a difference. The benchmark is fairly noisy. I agree with your conclusion, especially after looking at the input[1]. The strings are so small that the overhead of caching the UTF-8 decoding is probably comparable to the cost of doing UTF-8 decoding. [1] - https://github.com/christianscott/levenshtein-distance-bench...

Indeed, it looks like doing the UTF-8 decoding up-front is exacerbating the performance difference in the allocator. I think this is where the GP's first suggestion comes into play. If one were writing this code _and_ cared about performance, then you'd usually find a way to reuse allocations. I submitted a PR to demonstrate this: https://github.com/christianscott/levenshtein-distance-bench...