Hey, guys. I have kotlin mpp project and i’ve just managed to compile it for JVM and native (macosx)...

# kotlin-native

[4ntoine]

Hey, guys. I have kotlin mpp project and i’ve just managed to compile it for JVM and native (macosx). In my benchmarks native release app is ~10x slower than JVM one. This is how native target is added in `build.gradle`:

macosX64("native") {
            binaries {
                executable()
            }
        }

.
The measurements are done with trivial measureTimeMillis()

What can be the reason? Any optimizations turned off?

[Artyom Degtyarev [JB]]

https://github.com/JetBrains/kotlin-native/blob/master/RELEASE_NOTES.md#performance

[4ntoine]

Hmm

[4ntoine]

Any rough estimations compared to JVM when K/N is released (out of beta)?

[4ntoine]

Anything can be done to improve it at this point keeping in mind it’s not yet production-ready?

[Arkadii Ivanov]

Related discussion https://kotlinlang.slack.com/archives/C3SGXARS6/p1564440309086700?thread_ts=1564440309.086700&cid=C3SGXARS6

[Artyom Degtyarev [JB]]

What kind of code you’re comparing in this benchmark?

[4ntoine]

basically it’s ~ 80K of strings parsed into some classes hierarchy (lot’s of allocations i guess). Lot’s of regexps used

[Arkadii Ivanov]

Allocating is much slower in KN comparing to JVM. However it is almost same as native Swift.

[Arkadii Ivanov]

Better to move any parsing to background thread

[4ntoine]

Just out of curiosity i’ve benchmarked graal image for corresponding jar file and native image is a bit faster than jvm

[kpgalligan]

The performance question is definitely going to need a blog post. Comparing to JVM is tricky, and as mentioned, it’s a better comparison to Swift in a lot of ways. That’s not to say performance isn’t important, but we tend to do a lot of comparing to JVM because it doesn’t require much extra coding vs comparing to other languages.

[kpgalligan]

Strings, specifically, have compiler optimizations that will likely be added over time. Going from 1.3.3x to 1.3.4x had improvements in allocations and string handling.

[kpgalligan]

There are some things that will be slower in the JVM as well. For example, sqlite access, presumably because of JNI: https://github.com/square/sqldelight/issues/1226

[kpgalligan]

That’s about 5x faster on native (assuming I merged the changes, which I haven’t yet :)

[kpgalligan]

Comparing to the JVM today, though, will mostly be negative, but it depends what you’re doing, and taking a step back, figuring out where you need performance to be.

[Jeremy]

Many use cases tend to be bottlenecked by IO not CPU

[4ntoine]

Yup, in my case it’s not IO for sure. Having no [significant] performance improvement for K/N for the last 2 years (since https://github.com/JetBrains/kotlin-native/issues/670) is disappointing.. We already moved to Kotlin without proper K/N benchmarking and wanted to use it in production. Now it seems it becomes a blocker for some use cases. Anything we can do to increase the priority and/or contribute to achieve this goal?

[Artyom Degtyarev [JB]]

@4ntoine If you want to contribute to this exact goal, there are several ways you can do it. First of all, we’d appreciate if you can provide a benchmark to add it to our set of measurements.

[4ntoine]

Unfortunately the code i benchmarked is not open source at this moment. Can i share it with you without publishing?

[Artyom Degtyarev [JB]]

Yes, it won’t be published if this is your concern.

[4ntoine]

ok, what’s required from my side?

[Artyom Degtyarev [JB]]

The best of all would be if you can share a relatively small bunch of code(with build and run instructions), which performance can be easily measured. It got to represent some behavior, that, in your opinion, is the problem for your use-case. To deliver this project or file, feel free to use Slack DM.