In 2019, I will be participating in the Advent of Code using Kotlin multi-platform code only. This means I can run my solutions on the JVM, on Node JS and natively on Windows through MinGW.

I will be measuring the performance of each platform by measuring the elapsed time calculating the solution N times:

val times = (1..repeat).map {
    measureNanos {
        Puzzles.run(day, part)
    }
}

where repeat is the number of desired repetitions, and day and part are used to select the proper challenge.

Note that the measureNanos function is the first example of functionality that isn't available in common code, since measuring time is platform-specific. The function is implemented using Kotlin's expext/actual mechanism.

Runner.kt defines its expectation of a function measureNanos for each supported platform with the signature:

expect inline fun measureNanos(block: () -> Unit): Long

Each platform provides an actual implementation in files called Actuals.kt. On the JVM and native, we can use measureNanoTime as provided by the Kotlin standard library on these platforms:

JVM and Native:

actual inline fun measureNanos(block: () -> Unit) = measureNanoTime(block)

On Node, we need to write our own implementation:

actual inline fun measureNanos(block: () -> Unit): Long {
    val start = process.hrtime()
    block()
    val end = process.hrtime(start)
    val nanos = (end[0] * 1e9 + end[1]) as Double
    return nanos.roundToLong()
}

Usually, I try to finish a puzzle as quickly as possible, then spend some time to cleanup and optimise the code. If and when these optimizations alter the performance, I'll update the measurements below to reflect the new solution.

There is a very explicit warning in the FAQ of Kotlin/Native that says the current version of Kotlin/Native is not suited for performance analysis, as it has not been optimised in any way for performance and benchmarking.

Apart from that, all measurements were taken on my laptop, under non-controlled circumstances using non-optimized code and tools. So, if you use the results below for anything important, you're insane...

Last year, most days showed a similar pattern, with the JVM beating JS by a factor or two, and native being an order of magnitude slower than either.

This year's first puzzle shows a very comparable performance between JVM and JS, with native being much slower.

The solution for day 2 is very overdesigned, mostly because part 2 strongly hints that this is the first of several puzzles involving emulating this computer. So the code isn't the most performant, but hopefully it will help later in the month!

JS and native perform dramatically worse today than the JVM:

Update: for Day 7 I refactored the project to be able to use coroutines. I subsequently refactored the solution to Day 2 to search for the solution in parallel. New numbers are below as JVM-Parallel

TBD

TBD