Hello. Here is some general advice on Kotlin Multiplatform computational speeds across Android and i...

# general-advice

[Duane Malcolm]

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.

[Landry Norris]

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

[Landry Norris]

If you aren't very careful, there's a very high chance that Android's jvm detected that some values aren't used and is skipping the calculations.

[Duane Malcolm]

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.

[Duane Malcolm]

However, the point I was trying to make is to be careful trying prematurely optimize your code on iOS because there is a 5-6x difference between the debug and release build.

[Duane Malcolm]

I was actually wondering if there are some problems using lazy assignments to variables. I could try removing the lazy assignments.

[Klitos Kyriacou]

What do you mean by lazy assignments?

[Duane Malcolm]

@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.

[Duane Malcolm]

I just realised that this #general-advice channel is for asking for general advice - not really for giving advice. I'm not sure if there is a channel for this.
I'm not really asking a question, rather just warning developers that there is a 5-6x speed difference between a "debug" and "release" build on iOS physical devices so they should spend a day trying to optimize their code prematurely 🙂

[Landry Norris]

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

[Duane Malcolm]

@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.

[Landry Norris]

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.

[Duane Malcolm]

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.

[Landry Norris]

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.

[Landry Norris]

K/N is AOT compiled, so it doesn't get the same advantages as c2

[Duane Malcolm]

Ok, but iOS might not optimize these null check?

[Landry Norris]

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

[Landry Norris]

I'd like to see a Swift vs K/N comparison, since Java JIT compiles.

[Duane Malcolm]

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.

[Duane Malcolm]

I am thinking of using the Metal Compute shaders on iOS to compute the streamlines instead but this is a lot of work.

[Duane Malcolm]

Oh, I just had an idea. I can run the Android and iOS app on simulators on the same Macbook M1 - this should compare the apples with apple on the same hardware.

[Landry Norris]

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

[Duane Malcolm]

Hmmm, ok.

[Duane Malcolm]

I might just release the app to testers and see if they notice the time it takes to generate streamlines.

[Duane Malcolm]

Ok, this kind-of sucks. I tested the iOS simulator vs Android emulator on the M1. The iOS simulator took 1300-1400ms and the Android emulator took 400-500ms - ~3x faster.

[Duane Malcolm]

I did find this thread on performance the other day: https://kotlinlang.slack.com/archives/C0346LWVBJ4/p1670314482552089

[Duane Malcolm]

I still have one floatArrayOf call left in the code that generates streamlines so I might remove this too.