|
|
|
|
|
by brabel
1703 days ago
|
|
There are two or three branches with different versions of the Rust code, and the author is using the fastest one. What you believe will make the Rust code faster won't, trust me. If you think I'm wrong, could you please submit a PR and link here? @Cryptonic 's suggestions are laughable. Try using arrays as HashMap keys in Rust :D nope, won't even compile let alone be fast. There was a way smarter attempt here to do something *based on* arrays: https://github.com/renatoathaydes/prechelt-phone-number-enco... The DigitBytes struct is needed because just using arrays (I guess they mean slices, as arrays are obviously wrong) is incredibly slow - it would need to consider the whole array every time instead of just the relevant bytes - far slower than `Vec`. This is indeed fast, but slower than Vec. The other suggestion: print everything at the end?? Do we even know what the objective is here? It's not to finish first, but to show to the user the results as soon as possible. It's like people don't even read the problem proposition and still think it's ok to criticize... also, Rust is using buffered IO... ALSO, the benchmark only prints a single line at the end for the two last runs, essentially doing "print it all at the end". |
|
This is my original sentiment:
https://news.ycombinator.com/item?id=28842546
mst stated that the author explicitly called out the Rust code as suboptimal. That is a misreading of the original text, which was referring to a previous iteration. The author (and you) clearly does not think the current Rust code is suboptimal.