This is really dipping into "sacrifice programming convenience for performance" territory, but the savings are nice enough that I'll sacrifice a bit here. This drops my 50ms part 2 to more like 34ms.
Based on a suggestion from @tocchan I converted the total risk map from a Dictionary to an array and things really took off (125ms to 50ms on my machine in Release). And that's with a sub-optimal fill/memset of the array to int.MaxValue (which I couldn't find a better way to do without diving into `unsafe` territory), though that step only takes about 500us with this method anyway, so it's hardly the worst part.
This way I can have multiple timers in a given scope that measure different things without super awkward `using`s that end up scoping out variables that I need access to later. The timings get printed in reverse order, of course, but the conveniences provided outweight that minor flaw.
This is a small low-hanging fruit pass. I was really just curious where the time was going since I didn't feel like the algorithm was actually expensive. Turns out it's not, really...the larger cost is setting up the frequencies and pairs collections, and computing min/max was 9x more expensive than it needed to be (I was expecting 2x since I was iterating over the collection twice, but 9x is...unreasonable, so I just unrolled it myself). It also turns out that MinBy() is marginally slower than Min() with no gain (for this use case), so that was an easy win on the brute force solution.
For some reason, Console.IsInputRedirected is true when run under hyperfine even if we're not redirecting anything. I wonder if hyperfine is opening an input channel in case it's needed? Either way, the fix is pretty simply to try reading from stdin and then falling back to the file on disk if our input set is still empty afterward.
I'm sure there's a better way to strip the UTF-8 BOM from the beginning of the file (and/or use that information to actually handle the string appropriately) but this works for my use case. At this point, we support ASCII and UTF-8 in LE order with or without the byte-order mark and, I think, either \n or \n\r line endings as input text file formats.
This fixes my logic errors from the first attempt so the letters are much clearer now. It also swaps from trying to iterate over segments of a grid, pulling from later segments, to simply storing the list of marked points in a more efficient (and obviously smaller) collection that we add to and remove from when transforming points via folding, which is where the speedup comes from.
Fun fact: printing the result is about a quarter of the runtime of part 2.
Honestly I think I have an error somewhere in the part 2 logic because my final output characters weren't exactly correct, but they were close enough that my first guess for each letter was right. So I may revisit this to find and fix the logic bug, but apparently it's Close Enough™ to be done for the night.
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.
