Notable improvement in perf while switching "scree...

# compose

[Yann Badoual]

Notable improvement in perf while switching "screens" with a crossfade from alpha04 to alpha05, very nice

[Halil Ozercan]

Speaking of improvements, LazyColumn got a lot more performant with alpha05.

[Andrey Kulikov]

yes, we saw similar issue during our internal tests. @Alexandre Elias [G] could you share more details on what you figured out about that?

[Alexandre Elias [G]]

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.

[Alexandre Elias [G]]

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

[Alexandre Elias [G]]

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

[Yann Badoual]

Wow thanks for the explanation! I'll try asap, sorry for the delay my desktop died on me

[louiscad]

Are all the affected Android versions compatible with the Play Store delivered AOT?

[Sergey Y.]

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

[Zach Klippenstein (he/him) [MOD]]

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

[Zach Klippenstein (he/him) [MOD]]

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.

[Alexandre Elias [G]]

yes, manual use of dex2oat with --compiler-filter=speed also works. (I specifically tried that when I last investigated the issue)

[Alexandre Elias [G]]

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

[Alexandre Elias [G]]

@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

[Alexandre Elias [G]]

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

[Alexandre Elias [G]]

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