prechelt-phone-number-encoding

> it’s using Unicode-aware string stuff Rust uses UTF-8 internally for Strings, so it's very efficient to parse a file into a String, then using slices to go through it... this is probably the best you can get as parsing ASCII input as UTF-8 is very efficient (the 0-bit is always zero in ASCII, the unicode decoder only needs to check that's the case for every byte, so it's not some kind of complicated computation it's doing to decode)... If you use bytes for everything, you will make the whole code much harder to follow and it still won't run faster. Check for yourself: https://github.com/renatoathaydes/prechelt-phone-number-enco...

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

This is a pretty introductory CL article, mostly a commentary on Norvig's solution to the problem. Still, I learned about the #. readmacro from it. The conclusion: "[The Lisp implementation] was the fastest implementation for all input sizes except the largest one, where it performed just slightly worse than my best Java implementation." GH repo at https://github.com/renatoathaydes/prechelt-phone-number-enco.... Sounds like he was mostly measuring the performance of the SBCL bignum implementation.

It's always sad to see someone get burnt by the internet, I wish him, and also those who criticised him, well. On a brighter note, I appreciate the noob-friendly explanations. It made it really easy to follow along. I'm also really curious about how Java achieves better stdout performance. I hope we get to apply the lessons to other environments too! I didn't read all of it, so perhaps there's a clue in @bugaevc's PR[1] mentioned in the article. [1] https://github.com/renatoathaydes/prechelt-phone-number-enco...

> … his original code was n00btastic… Sorry, but this is at-least the second blog post, in the last week, and previously — "I've discussed the Rust and Julia versions with experts in those languages (—— I know Rust well enough ——, but very little Julia) and no obvious mistakes were found." https://www.reddit.com/r/lisp/comments/osqgqe/common_lisp_st... Before that, on finding the output from his Java program was different than the output from Peter Norvig's Lisp program — "It looks like Norvig's Lisp solution must have a bug: it can't find all valid solutions!" https://github.com/renatoathaydes/prechelt-phone-number-enco...

I don't recommend drawing too much of a conclusion from these tests, about anything other than printing in <your language>. Once the algorithm is somewhat optimized, the benchmark is completely dominated by printing to stdout, not the algorithm in question. Pulling from the near the conclusion here, bugaevc finds: "And the measured time reflects how long it take to actually compute the solutions (≈1.6s), not how much time it takes to output/buffer them (≈59s)." source: https://github.com/renatoathaydes/prechelt-phone-number-enco...