My Day 13 solution for Part 2 takes 1.5 seconds on my computer for my input.
The trick I used is to sort the firewall so I try smaller ranges first. They will more often disqualify a specific delay, so short circuiting the instant one fails skips a lot of work. I feel the code is still pretty easy to follow, since I just used Enum.any?/2 to handle the checks.
Yeah, I used any? as well and it helps a lot. It terms of simplicity as well as performance.
Good idea with the sorting! I added it to my solution and it shaved off about 10%.
This one is quite beautiful and to the point. Great job!
The funny thing is that my published solution uses the same approach, but it’s done in a lazy way through streams. I did expect some penalty for that, but not so much (more than 10x on my machine).
Thanks!
It would be interesting to see how much faster it would be with any? instead of filter. I think it should help a lot since for this problem only 1 out of 4M iterations goes through the whole list 
The problem is not in the filter, I’m using Stream.filter with Enum.empty?, so this stops as soon as we find the first severity for the given delay. The number of inner comparisons should in fact be the same. However in my solution there are three indirections in the inner loop (Stream.filter, Stream.map, and Enum.empty?), and this is where I guess the problem is. With the loop being tight and long, and inner calculation very simple, the overhead of streams seems to dominate a lot.
And day 15.
Those who know about Streams and especially about the fact that one can create them from thin air and does not need to have an Enumerable.t() to feed them, should be done in no time with this.
What bugs me a little is, that simply generating thus many numbers takes a lot of time.
Part a takes about 30 to 35 seconds and Part b 14 to 16.
Im wondering if handcrafting generator functions would sped up everything at least a little bit. It would remove some of the indirections of Stream, but introduces its own…
By generator function I mean functions that return a tuple with the next value and a function to generate the next tuple, roughly like this one:
iex(1)> defmodule M do
...(1)> def gen(input \\ 0), do: {input, fn -> gen(input) end}
...(1)> end
iex(2) {_, f} = M.gen()
{0, #Function<...>}
iex(3) {_, f} = f.()
{1, #Function<...>}
iex(4) {_, f} = f.()
{2, #Function<...>}
Okay, a noticable speedgain by using the aforementioned generators…
Part a went to ~12 seconds (~3 times faster) and part b to ~6 (~2.5 times faster).
Since I linked to the files on master branch, following the link in my previous post will take you to the version using generators, the older version using streams is available in the history of that file (thats why I keep them in version control).