hmm. that's not my observation: https://ephemient.github.io/aoc2022/jmh-visualizer/index.html
I'm not measuring build time, but execution times for K/N have been mostly consistently worse than GraalVM native-image (and both of them consistently worse than HotSpot)
ephemient
01/02/2023, 5:40 PM
kotlinx-benchmark isn't built for WASM yet so I don't have a comparison with that
s
sdeleuze
01/02/2023, 5:41 PM
Interesting, I will have a deeper look to you benchs. Mine is super basic and was raised as one where Kotlin/Native was super slow a few years ago, so it may have been optimized more than others.
o
Oleg Yukhnevich
01/02/2023, 5:45 PM
As far as I remember, K/N is much slower, when there a lot of allocations of small/short-living objects
s
sdeleuze
01/02/2023, 5:46 PM
Yeah maybe my sample does not involve enough GC pressure.
m
Michael Paus
01/03/2023, 11:19 AM
The table above makes Kotlin/JVM look bad due to the huge size of the full JDK. It would be interesting so see how much this could be reduced by just using a dedicated runtime produced by jlink. I think it should be possible to bring that down to the range of GraalVM or maybe even better.
s
sdeleuze
01/03/2023, 11:29 AM
I don’t think peak RSS would be lower than GraalVM due to the JVM infra that need to be loaded regardless of how much is used in the app, but I agree that would be an interesting data point. Feel free to send a PR.