https://kotlinlang.org logo
#compose
Title
# compose
y

Yann Badoual

10/16/2020, 7:10 PM
Notable improvement in perf while switching "screens" with a crossfade from alpha04 to alpha05, very nice
h

Halil Ozercan

10/16/2020, 7:11 PM
Speaking of improvements, LazyColumn got a lot more performant with alpha05.
👍 2
a

Andrey Kulikov

10/17/2020, 1:07 AM
yes, we saw similar issue during our internal tests. @Alexandre Elias [G] could you share more details on what you figured out about that?
a

Alexandre Elias [G]

10/17/2020, 1:33 AM
Yes, this sounds like the known issue that Compose apps are especially prone to delayed JIT on first install and scroll. ART doesn't realize what are the hot codepaths in your newly compiled app until you start scrolling, at which point it kicks off JIT compilation, and then 10 seconds later it's done compiling and scrolling is much faster after that.
note that this should be less of an issue for real users because Play Store collects stack trace profiles from real-world usage and AOT compiles the performance-critical part of the app. it's mostly highly visible to developers writing a new app and deploying locally, so we're considering adding an AOT compile list for known Compose hot functions to Android Studio "Run" workflow
to confirm that this is indeed JIT and not something else, you can force a full AOT compile of your app with the command:
adb shell cmd package compile -r [install|bg-dexopt] pkg_name
y

Yann Badoual

10/21/2020, 10:58 AM
Wow thanks for the explanation! I'll try asap, sorry for the delay my desktop died on me
l

louiscad

10/28/2020, 12:55 PM
Are all the affected Android versions compatible with the Play Store delivered AOT?
s

Sergey Y.

10/28/2020, 1:19 PM
@louiscad Only Android 10 and higher, if I not mistaken. And that doesn't solve the original problem - lag. There will always be users who experience these scrolling lags. It is kinda uncomfortable. And there are users on the older versions of Android or without Google Play services.
z

Zach Klippenstein (he/him) [MOD]

10/28/2020, 4:23 PM
@Alexandre Elias [G] Does using
dex2oat
with the
speed
compiler filter also fix this? (reading documentation at https://source.android.com/devices/tech/dalvik/configure)
we’re considering adding an AOT compile list for known Compose hot functions to Android Studio “Run” workflow
Would love to see this exposed for command-line builds as well, both for local development as well as running UI tests. We also have a bit of a strange use case, we deploy android apps to custom devices which have storage restrictions that prevent us from using the
speed
filter on all the apps indiscriminately, but we could probably use a specific profile just for compose code.
a

Alexandre Elias [G]

10/29/2020, 12:37 AM
yes, manual use of
dex2oat
with
--compiler-filter=speed
also works. (I specifically tried that when I last investigated the issue)
right, your command-line build use case sounds reasonable. we were talking about making a "specific profile just for compose code" by doing something like taking the intersection of profiles of 3 of our sample apps. aside from your storage restriction use case, the main reason we'll definitely want that is for build speed
👍 1
@louiscad for what it's worth, on pre-Android-10, there is another mechanism of overnight on-device
dex2oat
compile based on the user's local profile of recently installed apps
I agree it's "kinda uncomfortable" to have performance based on various heuristic systems. Compose-team is keeping an eye on this and we'll keep working on both improving the coverage of the heuristics and adding new 100% consistent mechanisms where it makes sense
AOT-vs-JIT is a very tricky tradeoff that Android has been circling and trying different approaches on since the beginning. In the past the tradeoff affected install time vs loading time; now with Compose distributing more view-layer code as part of the APK, initial scrolling perf enters the tradeoff space as well, so it's an opportunity to revisit and make sure we're striking the right balance