After hearing about the performance improvements f...

# kotlin-native

[spierce7]

After hearing about the performance improvements for 1.3.70 I thought I’d try out my html builder benchmark again. The entire lib basically compiles down to a giant StringBuilder with inline functions.

I’m still seeing that building a website 10k times takes ~400 millis on JVM, and about 10X that for Kotlin/native with target macosx64 at ~4100 millis.

https://github.com/ScottPierce/kotlin-html/tree/master/benchmark
./gradlew :benchmark:runReleaseExecutableMacosX64 if anyone else wants to try.

[Dominaezzz]

The improvements were mostly compilation times iirc.

[spierce7]

There were some other performance things I remember reading about allocating certain things on the stack instead of the heap. I don’t know. Either way the performance needle hasn’t really moved

[Elena Lepilkina]

Thank you for sharing your benchmark!
Several points:
1. It's known issue that operations with strings are slow in K/N now. And your benchmark shows exactly this case. We'll work to improve this, but it's only one case and mostly real world application contain several other tasks, although we understand that effective work with strings is important.
2. > I remember reading about allocating certain things on the stack instead of the heap
You are talking about local escape analisys, it was implemented but it cann't work with strings at least now, because it's local so works only inside one function, all operations with strings in Kotlin/Native now are functions, so strings can't be allocated on stack.

3. Also, please, pay attention in future on your way of measurement. For current case it doesn't matter, because difference is huge, but in other cases it can be important. Your measurement for JVM includes warmup phase, for native it's also needed, you have to warmup processor caches before measurement to decrease cache misses. Also you use printing during you measurement at least value of benchmarkTotalMillis includes it and it's bad practice. You should avoid printing during measurement.