People seem to love coming into the Rust community and then saying - hey, I did this micro benchmark after just learning rust - and XYZ language is faster!

Anyone who's been writing rust for a little bit will notice the String clone like a sore thumb. The "go-to-perf-guide" also very explicitly states than clones on String/Vec/Box etc will cause an allocation and slow down your code.

https://gist.github.com/jFransham/369a86eff00e5f280ed2512145...

In every one of these micro benchmarks, the comments will then show that by removing the alloc, the Rust version ends up much much faster.

String cloning is one of those things you learn to avoid early on, and any time you type "clone" it should be obvious that there's a better way to write your algorithm.

Sounds like a good read, do you happen to have a link?

EDIT: https://cesarvr.io/post/rust-vs-javascript/

I think the following minor optimizations can further decrease the runtime:

* There is no use in first pop()ing a candidate from the "reacts" list and then potentially re-pushing them later. Getting a pointer to the last element, and removing it if it is not needed, is more efficient.

* Reordering the character equality condition could help a tiny bit since the inequality check should be faster than the ignore case check.

> Reordering the character equality condition could help a tiny bit since the inequality check should be faster than the ignore case check.

I think the given ordering is better: in a conjuction, you typically put the less likely condition first, not the cheaper one.

Good point. Here it is premature optimization anyway and too dependent on the input. In general, I think a balance between likelihood and cost should be found.

Out of curiosity, I just did a small benchmark (criterion) using the input.txt provided, and reordering results in a 10% difference:

  Old Order time:[307.28 us 309.12 us 311.17 us]
  Reversed  time:[270.82 us 271.18 us 271.54 us]

This feels weird since the input.txt contains few pairs of equal characters, so there is likely something else going on. The inequality is very inexpensive but the ignore case compare should not be that expensive either.

What if you add PGO to the mix, how fast it is going to be?

Weirdly enough, PGO equalizes and increases the runtime, where both methods take approximately 330 us. (I simply applied PGO to the full benchmark harness, no idea if this is proper). Them being equal sounds more reasonable, but the increase in runtime doesn't feel right.

Micro benchmarking remains a fickle beast :)

I remember the talk where two different users measured different performance due to the username length..