Hello. Here is some general advice on Kotlin Multiplatform computational speeds across Android and iOS. I have some computationally expensive code that calculates 9-10 million floats. I was able to get Android debug builds (from Android Studio) to compute this in 600-700ms on a real phone, an iOS build (Xcode) on a Macbook M1 simulator to compute this in ~1400ms, and a iOS build on a real 2018 6th gen iPad to compute this in ~16000ms. This is 25x Android!!!. Clearly this is not a cool user experience. I spent a whole day trying to fix this to no avail. The next day I built a proper archive of the app and uploaded it to Test Flight. I installed this build on the same iPad and the computational time was about 3000ms which is reasonably ok UX. So the general advice is that there is a 5-6x improvement in speed between "debug" and "release" builds on iOS.

Android uses the JVM, which will optimize loops on the fly.

As part of spending a day trying to improve the iOS times, I prematurely optimized the code and reduced all times by 2x, i.e., Android was ~1300ms down to ~650ms, which was a good result.

What do you mean by lazy assignments?

@Klitos Kyriacou I'm not sure how efficient having a

lazy

assignment is compared to a having a constant value. I'm guessing

lazy

will add some extra checks, hence extra cost, when I get the value.

Lazy is just a wrapper for a null check. Every access will check if null, then run the lambda if it is.

@Landry Norris That's exactly what I thought it would do but didn't really know. So I plan to check why this code is much slower on iOS than Android. I plan to rewrite the code in Swift to compare speeds to determine if it's a KMM thing or the iPad is just slow compared to my Android phone.

Looking at the timing and the number of loops, I'm not sure I believe the Android's actually running the calculations. Is this a practical example, or a synthetic benchmark? If the floats aren't used for anything, the jvm will skip calculating them eventually.

This is a practical example. I'm calculating streamlines based on wind data. The code calculates the location of point along a streamline. There are 9-10M points and are calculated and stored directly into a pre-allocated

FloatArray

. It would be doing this

lazy

null check 9-10M times - I'm not sure how expensive this is.

The c2 (java's most aggressive compiler) is really good at optimizing null checks, so they essentially don't exist when the c2 kicks in.

Ok, but iOS might not optimize these null check?

iOS doesn't allow JIT compilers, so it can't optimize them as well.

Ahhh, I see. This is why I'm trying to manually optimize the code for iOS can run faster. I really don't know if it's the hardware difference or compiler difference. I can't imagine there is much in my code the JIT compiler can improve on - all values are calculated and sent to the GPU.

Android'll have some overhead due to qemu. On iOS, the simulator runs on the metal. Hence the 'android emulator' vs 'iOS simulator'

Hmmm, ok.