Like last year, I will try to solve the puzzles us...
# advent-of-code
j
Like last year, I will try to solve the puzzles using only Kotlin common code, and do some naive performance measurements of the solutions on the JVM, in Node and native on windows. Results are logged at https://github.com/jorispz/aoc-2019. Today I was pretty surprised that the native code took longer to run on each iteration (I run every solution 25 times in an internal loop). First iteration takes about 3ms, then it quickly increased to around 30ms. I have no clue what happens there. Averages for today: JVM 3.07ms, Node 31.39ms, Native 23.88ms
🏁 1
👍 2
k
It could be the K/N garbage collector kicking in that makes it run slower?
(and a tip:
keepApplying
already exists as
buildSequence
)
j
I don't think
buildSequence
does what I need it to do? (and it has been deprecated in favor of
sequence
, which I do use.
k
Ah sorry, I meant
generateSequence
j
Ah great, thanks! I looked for this but couldn't find it, very nice
I have been fiddling around a bit, it turns out it's scrolling the console is what actually makes the native stuff slower over time!
Not sure if it's the same for JVM and Node, I'll have to check. But if I clear the console beforehand and make it large enough to fit all the output, every iteration takes a few ms
k
It takes 20ms just to print two lines to the console? That's strange, I thought that was load for the terminal instead of the program itself.
j
Yeah, that would logically be the terminal process, not my code. I actually run the JVM solution from IDEA, and node and native from PowerShell. I'll dig into this, because this makes my measurements even more useless than they were anyway 🙂
k
j
Using cmd.exe instead of powershell didn't make much of a difference, but running the executable from IDEA (and thus using IDEA's console) solved it, and I now get around 3ms duration consistently. I would never have guessed....
k
Powershell and cmd use the same terminal so that would make sense.
j
Native now actually beats the JVM!
Only on the first run though, the JIT wins in the end. I'll update my repo
k
Could you also test without sequences? They cause boxing and I'd be interested to see who handles that best.
j
Sure! Also, I reran the NodeJS solution in IDEA's console, and same thing - dramatically better execution times. Now all three solutions are really close
k
Also maybe increase the amount of repeats, one millisecond is not a lot to measure.
j
I'm actually measuring nanos, but reporting ms for brevity (and because later days run into multiple digit ms anyway).
k
Right but still, it's also about variability.
t
I think it's so cool you are doing this again.
j
Thanks, Todd! And likewise, happy to have see you blogging again this year! Not sure how far I'll come this time around, it's going to be a busy month.
OK, I switched to reporting microseconds instead of millis, which gives a bit more insight into the variance of the measurements. @karelpeeters I'm gonna bail on examining the effect of (un)boxing, this has been enough of Day 1 for me....
k
Sure, don't feel pressured by me 🙂
j
👍
The plot thickens! Yesterday, when I experienced the slow console output, I was at home working on my laptop screen at (3840x2160 at 250% scale). Today at work I wanted to show the problem to a colleague, so I dragged the console to my second monitor (3440x1440 at 100% scale). Lo and behold, on the second monitor the problem doesn't exist! So somehow writing to the console in a shell running on the laptop screen is an order of magnitude slower than on the second monitor. If I get to it I'll see if it's the scaling or something else.
😮 1