Has someone already the new memory model in produc...

# kotlin-native

[Paul Woitaschek]

Has someone already the new memory model in production use? From the introduction I was kind of blown off to use it (report if performance is >5x worse)
I did a benchmark on one of our data intensive flows and actually its faster with the new memory model (6seconds -> 4seconds).
Is there info on which code paths are expected to be slower?

[kpgalligan]

I'm also super curious about anybody's prod experience. We're likely to start piloting in prod, but smaller footprint apps that don't really have heavy performance needs, so I wouldn't expect to run into much.

[Elena Lepilkina]

Hello! Results on different code of course can differ. We provided that average estimation basing on our benchmarks set (including microbenchmarks).
The code examples where new MM works much worse than old one in 1.6.0 version are provided here https://gist.github.com/LepilkinaElena/51a93cab661c49b0c480c49b78dbe7d4
(Fibonacci calculation is worse on new MM in 7.61 times on new MM, average results after warmuping)
A bigger example can be the next https://gist.github.com/LepilkinaElena/9e8e91e5c2e1205ee605c5e07d8c3ed6 (it's worse in 4.83 times on new MM, average results after warmuping)

[Elena Lepilkina]

But of course at the same time we also have benchmarks in our set that showing results better up to 3 times with new MM

[Elena Lepilkina]

Most of our benchmarks are in our repo https://github.com/JetBrains/kotlin/tree/master/kotlin-native/performance

[Paul Woitaschek]

Interesting! Have you on a meta level already found out which type of code generally performs better and which performs worse?

[Paul Woitaschek]

Btw I think these don't do what you expect
https://github.com/JetBrains/kotlin/blob/f38e1b218dc3e0a042f6c7a94365a3c6a578f035/kotlin-native/performance/build.gradle#L349
DependsOn iirc doesn't give any order guarantees

[Elena Lepilkina]

Have you on a meta level already found out which type of code generally performs better and which performs worse?

We are looking on performance of new MM and working on it. We know some problems and some of them are solved or are in process. There would be some performance improvements in 1.6.20 for new MM, but we now don't plan to give some recommendation how to rewrite your code if you are interested in this point because we have a goal to get comparable performance with old GC and now there is active development process when everything is changing quite fast.

[Paul Woitaschek]

But is the current implementation still: freeze the world and garbage clean?

[Elena Lepilkina]

Now (1.6.0) stop-the-world mark and sweep . There would be possible to turn on with flag -Xgc=cms stop-the-world mark + concurrent sweep in 1.6.20 (later it should become default), next steps of improving are also possible but it's too early to talk about them.

P.S. There was a discussion with same question https://kotlinlang.slack.com/archives/C0A974TJ9/p1639469867084000?thread_ts=1638021189.413100&cid=C0A974TJ9

[Elena Lepilkina]

We'll appreciate if you find and share with us examples of code similar to production one that is slow with new MM and check you projects with -Xgc=cms in 1.6.20

[napperley]

There is one case I can think of where the new MM works better than the old one. Embedded GUI applications running on Embedded Linux (eg via linuxArm32Hfp target) where the memory usage is lower, and the binary size is smaller.

[caffeine]

I have been using it in production for two days now. While researching how it works. So far so good.