6 ms·

He figures that out in his 2nd article, where he now finds Rust is 1/8th of the time of Node.js.

lionkor 6y ago
Sounds like a good read, do you happen to have a link? EDIT: https://cesarvr.io/post/rust-vs-javascript/ https://cesarvr.io/post/rust-vs-javascript/
- gregod 6y ago
  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.
  - creata 6y ago
    > 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.
    - gregod 6y ago
      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.
      - rossmohax 6y ago
        What if you add PGO to the mix, how fast it is going to be?
        gregod 6y ago
        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 :)
        renox 6y ago
        I remember the talk where two different users measured different performance due to the username length..
jkelleyrtp 6y ago
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/369a86eff00e5f280ed25121454acec1 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/ https://cesarvr.io/post/rust-vs-javascript/

gregod 6y ago
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.
- creata 6y ago
  > 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.
  - gregod 6y ago
    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.
    - rossmohax 6y ago
      What if you add PGO to the mix, how fast it is going to be?
      - gregod 6y ago
        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 :)
        renox 6y ago
        I remember the talk where two different users measured different performance due to the username length..

jkelleyrtp 6y ago

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/369a86eff00e5f280ed25121454acec1 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.