And so this series of posts comes to a close. I hope I was able to help you learn something - I certainly did while developing these solutions. Even writing these posts, as I went through the solutions again I found an additional 34 ms of time save even after I’d decided that 164 ms was a good enough time to settle on.
My main reflection after all this is that if you want to write fast programs, the first and most important thing to do is to make it easy to measure performance. Once that is set up and you can test ideas against hard, objective observations, you can start poking around and see what happens. It actually turns out to be surprisingly easy - at least in Rust, but really one of the most important factors is being familiar with some standard data structures and their strengths and weaknesses. Algorithms also make a big difference, of course, but it can be quite impressive to see a program run some 6 times faster just by changing a collection from a hash map to a vector.
Another reflection is, of course, that Rust is indeed blazingly fast.
It’s one thing to read about zero-cost abstractions as an idea,
but another to see firsthand that iterators and other high-level concepts
are indeed just as fast or even faster than a traditional for loop.
Still, you do need to mind your data -
subtle things like
Vec you don’t really need
can have a surprisingly large impact on performance.
The good thing, though, is that it’s often easy to know when you’re being inefficient,
as there’s often a
I’d like to thank Eric Wastl for making Advent of Code these last few years. They’ve been a lot of fun to solve, and a great way to practice a new programming language. I’m looking forward to this year’s edition. And of course: thank you for reading, and good luck with your current and future projects!