Since in day 13 I saw a huge performance overhead of streams in a tight long loop with simple inner steps, here I immediately decided to roll a plain recursion. It takes about 3 seconds for each part on my machine. Here’s my solution.
sasajuric
Author of Elixir In Action
NobbZ
Your way definitively works better than mine, I guess it is related to constantly wrapping the function call into a closure and passing it around.
I tested your code on my office VM and with my input and they run in 6/4 seconds respectively. Thats a gain of factor 2/1.5.
All I did to get times for each part, was to slightly alter the runners:
args = System.argv() |> Enum.map(&String.to_integer)
:timer.tc(Day15, :part1, args) |> IO.puts
:timer.tc(Day15, :part2, args) |> IO.puts
0
kwando
Here is my solution to day 15. I’m curios what you all think about the “dispatch pattern” I’m using here, is it fine or am I flirting to much with OO?
1
NobbZ
kwando
thanks!
petecorey
Here’s my day 15 solution. At first, I was doing a wonky little endian + padding bitstring pattern match:
padding = <<0x00, 0x00>>
<<a :: 16, _ :: binary>> = :binary.encode_unsigned(a, :little) <> padding
<<b :: 16, _ :: binary>> = :binary.encode_unsigned(b, :little) <> padding
a == b
But I quickly realized that was just a poor man’s bitmask, and replaced it accordingly:
(a &&& 0xFFFF) == (b &&& 0xFFFF)
I feel like there’s some clever solution based on the significance of the mod number he chose, but I’m not clever enough to figure it out.
0
sasajuric
Author of Elixir In Action
There is certainly more “stuff” happening with Streams compared to plain recursion. As you say, there is the closure indirection, and also there’s constant wrapping into and unwrapping out of :suspended tuples, and there’s manual iteration through all the composed functions. See Enumerabl impl for Stream for details.
My guess is that when the actual work in each iteration is fairly simple and short, the running time gets significantly dominated by the stream overhead. Two days ago, compared to my streaming approach, the recursive solution by @mitja reduced the running time by the factor of 20 
TBH, I didn’t use streams a lot in real work, so I decided to practice them through AoC. I really like how they are highly composable, and how I get the stable memory usage just like with recursion. I think I’ll be using streams much more in the future.
That said, in the code which is highly CPU bound and performance critical, the penalty of streams can become too high, and falling back to plain-old recursion can help significantly.
0
NobbZ
I wasn’t talking about streams here, but about my generator approach which takes about twice as long as your solution and there aren’t much differences between our code.
0
NobbZ
Day 16…
Wow… That wasn’t expected… Part 1 was done pretty quickly, part 2 suffers from a massive performance problem… When I reduce the number of iterations to 1_000, I need ~20 seconds, and I’m not really fund of the idea to adjust the timeout… If its linear, I need to set it to roughly 232 days…
As I already have experimented with NIFs using :rustler for day 10/14 combo, I think I will use a NIF here as well, I really can’t come up with an idea to improve the performance by the factor ~500_000 otherwise…
0