https://kotlinlang.org logo
Join Slack
Powered by
Hello. Here is some general advice on Kotlin Multi...
# general-advice
d
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.
l
Android uses the JVM, which will optimize loops on the fly.
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.
d
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.
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.
I was actually wondering if there are some problems using 
lazy
assignments to variables. I could try removing the 
lazy
assignments.
k
What do you mean by lazy assignments?
d
@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.
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 🙂
l
Lazy is just a wrapper for a null check. Every access will check if null, then run the lambda if it is.
d
@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.
l
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.
d
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.
l
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.
K/N is AOT compiled, so it doesn't get the same advantages as c2
d
Ok, but iOS might not optimize these null check?
l
iOS doesn't allow JIT compilers, so it can't optimize them as well.
I'd like to see a Swift vs K/N comparison, since Java JIT compiles.
d
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.
I am thinking of using the Metal Compute shaders on iOS to compute the streamlines instead but this is a lot of work.
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.
l
Android'll have some overhead due to qemu. On iOS, the simulator runs on the metal. Hence the 'android emulator' vs 'iOS simulator'
d
Hmmm, ok.
I might just release the app to testers and see if they notice the time it takes to generate streamlines.
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.
I did find this thread on performance the other day: https://kotlinlang.slack.com/archives/C0346LWVBJ4/p1670314482552089
I still have one 
floatArrayOf
call left in the code that generates streamlines so I might remove this too.
Open in Slack
PreviousNext
Powered by