I don't understand why this keeps breaking. I guess a char can be more than a byte, which makes sense, but I also don't understand why these files (which multiple editors claim are utf8-with-bom) are prepended with apparently utf32 characters or something. Anyway, hopefully just embedding the array I'm seeing and comparing against that will work...
I would have had this done last night, but... _unintelligible muttering about key[0] being '#' in the real input and '.' in the sample...
Day 19 is...still vexing me. Maybe I'll get back to it later.
These are pretty rudimentary and I'd like to expand them, but I don't know that I'll need them for future days, so I'll solve that problem if I need to later.
I have a very strong feeling that I massively over-complicated this, but it works. I spent a ton of time making sure each component of the problem was implemented correctly so I could quickly identify where things went wrong, and that setup was convenient enough that I just formalized it and left it in. Maybe it'll be useful for another day...
You'd think I'd have learned my lesson about Dictionaries by now. They're great, but only for sparse input sets or where lookup needs to be as fast as possible and other access types are less important.
The string colorizer is slow (but apparently only the first time it runs, for some reason?), printing can be slow, who knows what else the framework is doing, etc., so manually inserting Stop()s exactly where we want the timings to stop is the most reliable way to handle this. I like the elegance of the disposable solution, but my goal here is to measure the actual algorithm, not anything else.
A slightly restructuring would make it so I don't have to do this; if main.cs was receiving a string from Part1 and Part2 instead of having each day individually print its own results, we could scope timings to exclude any console writing. But whatever.
I also went ahead and made 17 only run once since I was using the same result to answer part 1 and 2. I've since discovered that part 1 is far simpler and can be found without solving the entire problem space, but whatever.
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.
