Hello all. Did anyone encounter huge lag and FPS drop for the first ~5-10 seconds when a screen with...

# compose-wear

[Bogdan C]

Hello all. Did anyone encounter huge lag and FPS drop for the first ~5-10 seconds when a screen with ScalingLazyColumn is used? I switched to Column + .verticalScroll() and it's much better.

[John Nichol]

Is this is debug mode from Android Studio? The simple answer is that yes we see some performance issues when not in release mode with baseline profiles installed. There is a lot going on and you need to have all of the optimisations from release mode and JIT optimisations in place. Once you have those we are not seeing any performance issues

[John Nichol]

@Steve Bower [G] Do we have public docs explaining how to make sure apps are installed with baseline profiles and to check to make sure that the optimizations are being applied?

[Bogdan C]

@John Nichol Thanks fo rthe reply. It's not related to a mode, no matter if it's debug/release, on the emulator it works without issues, but on a real device it's laggy.

[Kseniia Shumelchyk]

Here is the recently released public guidance for core compose performance: https://developer.android.com/jetpack/compose/performance#config
it’s applicable to wear as well.

[Kseniia Shumelchyk]

@Bogdan C As an reference you can check the baseline profiles that we added to compose wear os sample: https://github.com/android/wear-os-samples/pull/250/files
and experiment if you see jank with and w/o baseline profile

[Steve Bower [G]]

Hi - in addition to the links Kseniia provided, see the official documentation on baseline profiles at goo.gle/baseline-profiles and the segment on baseline-profiles in the I/O talk on Compose Performance Gotchas (at 15min 26secs) -

https://www.youtube.com/watch?v=EOQB8PTLkpY▾

[Steve Bower [G]]

Some commands you can use to help working with baseline profiles:
1. adb shell dumpsys package dexopt | grep -A 1 $PACKAGE_NAME
Look at the status - if this doesn't have status=speed-profile, the rules have not yet been applied to optimize the app
2. adb shell cmd package bg-dexopt-job
Triggers running the optimization (applies to all APKs, not just your package, so can take a minute or so to complete the first time). The app must have been launched in order for the profile rules themselves to have been installed, ready for optimization. Usually, this command is run in the background when the device is idle, but you'll want to kick it off before performance measurement.
3. As an alternative to (2), you can set Wear OS to optimize with profile rules at installation time instead of runtime, like on Mobile:
adb shell setprop pm.dexopt.install "speed-profile"
(check by running adb shell getprop | grep -i "pm.dexopt.install")
Then, use adb install-multiple to sideload the profile at installation time - see 'Sideload the baseline profile' here:
https://developer.android.com/topic/performance/baselineprofiles#measuring-baseline
[there are a few steps to doing this, but you can wrap them up as a single script for ease of use]

Whichever way the app is optimized - be sure to measure performance after the optimizations from baseline profiles are applied to get the best measure of real-world performance.

[John Nichol]

@Bogdan C have you had a chance to run with profiles installed and confirmed to be working - I would like to ensure that the issues you are seeing are down to known issues with initial application optimisation and Jitting which we are already aware of rather than a different problem that will be seen in real world app deployment