Down to ~98ms from the original ~940ms. That's a very respectable gain, but I am still not quite happy with the runtime. At this point, though, I think I will need to re-think my approach rather than making small tweaks.
First round of the lowest of low-hanging fruits to get day 12 runtime from ~1s to ~280ms on my machine in Release. Still not happy with 280ms, so I will probably keep digging.
This was my initial solution I used to submit the puzzle answer. Runtime for part 2 on my input set was around a second, so now I'm going to find optimization targets. I'm sure there's a lot I could be doing much better.
Pretty happy with this one overall. I tripped myself up on part 2 and caused a huge headache by not realizing that I was passing the already-modified array from part 1 into part 2. I left some code to copy the 2d array because that was my original solution (and it's not straightforward to copy jagged arrays), but then realized that the synchronized flash doesn't happen until after step 100 (at least for my input and the demo input) so we can just account for that in part 2 and pick up where part 1 left off.
I like this tradeoff of running a single day in isolation so the output isn't muddied by other days but also being able to go back and run previous days' solutions (for comparison with friends also participating in advent). The only thing I wish I could do here is run "all" to fire them back to back, but this particular implementation doesn't allow that easily. Maybe later...
Purely for curiosity/benchmarking-against-identical-Rust-version reasons
Spoilers: Rust is somewhat faster than Go and very much faster than .net
...though presumably .net's problem is purely startup time
I feel like this solution is a little cleaner/clearer. Same concept, just cleaned up the code a little more to my usual style. Some parts are a little bit slower, but I don't mind too much for this purpose.
As always, plenty of room for improvement, but I'm reasonably satisfied with the core implementation. I'm honestly not sure why the Distinct is needed in the GetBasinSize() result as it's supposed to not even add the point if the point is already in there, but it's late so I'll check that out later.
I hate almost everything about this solution. It's all awful and a product of constantly adjusting how I was solving the problem to try and get the correct answer, so there are vestigial pieces of each road I headed down. Then I ended up using some combination of all of those pieces to get the actual answer, and...well it just needs to be overhauled dramatically. But it works, so I guess mission accomplished.
I'm reasonably happy with this one. I'm sure there's an easier way to determine the smallest distance, at least for part 1, but this works fast enough for me.
There is a lot to be disliked here, starting with the Line Length calculation, which I'm sure I'm just totally overthinking or otherwise being dumb about, to the way I'm picking the next point while moving along the line.
Also, TIL how much of a difference a good GetHashCode() override can make when comparing/equating custom struct instances. Not implementing GetHashCode() on this solution resulted in ~250ms runtime on my PC. Implementing a "bad" GetHashCode() (which was `return x.GetHashCode() | y.GetHashCode();` which seemed fine to me ¯\_(ツ)_/¯) resulted in >1s runtime on my PC. Using this implementation (HashCode.Combine()) results in ~25ms runtime on my PC. Those numbers are with nothing changing other than the implementation of GetHashCode() on struct Point.
I also disabled nullability in my quest to improve performance here. The compiler was complaining that my Equals() override wasn't equivalent because of nullability, so it had to be `object? obj` which I didn't care for since this was a value type and not a reference type.
I have no idea what I'm doing in Rust, and I definitely don't understand
borrowing yet, so this is a hideous solution on multiple fronts. I'm not
sure that I'll be sticking with Rust as AoC doesn't feel like a
conducive environment to learn it in.
