<@UBW2MSDDK> <@U2F3C51T8> Curious about what each of your tech stack looks like? Compose obviously, ...

# compose-wear

[yschimke]

@Tgo1014 @bod Curious about what each of your tech stack looks like? Compose obviously, but Coil for images? something else? Do you plan a tile for your app? Feel free to respond 1:1, or not at all.

[bod]

My app is Cine Today, it's a small "pet project" kind of app, which is already on the store. I've been working on it for a few years.

It's meant to show the list of movies playing today at your favorite theaters. It syncs from a (unfortunately, not public, and also France-only) API once a day.

I've started a few weeks ago re-writing the app from scratch, in Compose, and trying to follow modern arch practices.

Yes, using Coil for images 🙂

Current Views version / Ongoing rewrite.

One more note: currently the rewrite is very slow on a real watch, to the point that it's unusable. Note that I haven't tried with a release build, only debug builds. But it's worrying.

[yschimke]

It's exactly what you guessed

[yschimke]

Never run a debug build on a device for use

[Tgo1014]

@bod I had the same, debug is super slow on a real device but release looks nice 😄

[bod]

Good to hear. I'll try a release build soon 🙂

[bod]

Oh and yeah the current version has a Tile, and so planning the new one to have it too.

[Tgo1014]

Do you have an image of the Tile? Maybe I can steal your design 😂 Just kidding

[bod]

haha 🙂 It's just a very simple list of the movies. Also each text is supposed to have a different color (which is extracted from the poster with Palette) - but I guess it's a bug because they're all white today. 😅

[bod]

(also it's badly cropped - I guess I should have used maxLines=1)

[Tgo1014]

Can you scroll on a Tile? No right?

[bod]

that's a nope 🙂

[Tgo1014]

I wonder if you used maxLines 1 if it would get the proper width on the lines at the top where there’s less space

[bod]

I think not but maybe there are ways around it

[yschimke]

@Ataul Munim do you know about text wrapping on a tile?

[Ataul Munim]

I don't - but in my understanding, wrapping isn't supported. I would have expected ellipsizing to work though.

@bod have you had a chance to look at the tiles material components alpha?

[bod]

have you had a chance to look at the tiles material components alpha?

Not yet!

[Yingding Wang]

Is compose slow with your app while first time you open it? Is it faster, wenn you open your app second time? Should that be the case, it might be the JIT.

[Tgo1014]

This happens to me, sometimes after a while it gets up to performance.

[yschimke]

There are obviously other things it can be. You can look at macrobenchmark, or jankstats

[bod]

👍 I'll investigate more.

[yschimke]

There is definitely a JIT effect. Through the play store, and possibly depending on models, baseline profiles speed up generally most of the important androidx libraries.

[yschimke]

If you think it's this, then you can confirm it using macrobenchmark which can show the effect of baselines profiles, or even without just jitting.

[yschimke]

This is a good intro article https://medium.com/androiddevelopers/measure-and-improve-performance-with-macrobenchmark-560abd0aa5bb

[yschimke]

If it's a compose bug, in AS EE, you can see the composition counts to see whether it's doing too much work.

[yschimke]

Or dig into it with https://www.jetpackcompose.app/articles/how-can-I-debug-recompositions-in-jetpack-compose or https://chris.banes.dev/composable-metrics/

[yschimke]

Internally our belief is in general that when comparing like for like, with correctly optimised release builds. Performance is inline. Their isn't a big roadmap item to fix performance. So it's definitely worth us understanding why you are seeing worse performance.

[yschimke]

What would help is a like for like reproduction, showing worse performance. We can also confirm you are running with right build settings like minifyEnabled and shrinkResources.

[yschimke]

We take this seriously, so would love to work out how to help fix this. Unfortunately this is often the first reaction, but still to this point I don't think (or at least remember) we've found a case where it's slower when setup correctly and obvious compose performance bugs avoided.

[bod]

thanks a lot for all the resource! I'll definitely dig 🙂

[yschimke]

Yep - but also use me/us. We want to find out why things are slow and solve them before other developers hit them. Or at least consider as you have conclusions post them here, "show your working" 🙂

[bod]

oh yeah for sure! My first step will be to have a very basic app that just show a basic list. If there's already a perf issue at this point I'll ping you.

[bod]

(working on this evenings and week-ends however so won't be too reactive)

[yschimke]

Thanks, and yeah, do what ever you need, and we'll respond in time. Thanks for having the discussion on this, feedback helps.

[John Nichol]

For older devices the baseline profile will not be applied immediately you install the app. You can force the profile optimization to run which will give you a chance to see how the app will run when optimized @Steve Bower [G] can you provide instructions

[John Nichol]

On newer devices/builds the baseline profile optimization will run on app install.

[Tgo1014]

@John Nichol still we need to generate it manually and ship with the app right?

[John Nichol]

So there is a window for older devices where even a release build app when installed is not at its full performance - I agree this is sub-optimal

[John Nichol]

The library has the profile

[John Nichol]

and if you leave the device on change it will get applied

[John Nichol]

you can generate a app profile to potentially get further benefit, but a lot of the benefit will be realised when the Compose for Wear OS and Core Compose library profiles are installed

[John Nichol]

We got a change made to Wear OS so that base profiles get run on app install - but as I say that doesn't help older devices/builds which will wait and run the optimisation later

[bod]

thanks for the info! Interesting stuff.

[Steve Bower [G]]

Regarding John's point about triggering the profile optimization:

// Get current status (put your own $PACKAGE_NAME).
// 'quicken' means not yet optimized, 
// 'speed-profile' means optimized.
adb shell dumpsys package dexopt | grep -A 1 $PACKAGE_NAME | grep status

// Trigger background optimization - can take ~minutes to run
// but tends to be quicker after the first go
// (this optimizes all packages)
adb shell cmd package bg-dexopt-job

[bod]

very cool, thanks!

[Yingding Wang]

@Steve Bower [G] Thanks, Trigger background optimization behave interesting on Wear OS preview AVD rev10 for debug build.

Before Optimization Trigger:
   x86: [status=run-from-apk] [reason=unknown]
After Optimization Trigger:
   x86: [status=quicken] [reason=bg-dexopt]

Even debug build is quicken after optimization trigger, it feels to me my compose activity speed up also. Strange.
Is the optimization only for the release build for playstore? and not for the debug build?

Edit: I haven’t activated baseline profile yet for my app on wear os. minify and shrink only for release build and not for debug build.

[Steve Bower [G]]

I don't know what the optimization would do for a debug build - the recommendation is only to measure performance with release builds and with minify/shrink turned on, as you've noticed.

[bod]

lol I've ran adb shell cmd package bg-dexopt-job 15 minutes ago and it's still not over 😅

[yschimke]

Nice repro. I haven't run it, others know the perf story a lot better than me. But from quick glance, the build file looks sensible, and the UI functionality looks like something that should be handled nicely. Nothing crazy going on.

[yschimke]

@Steve Bower [G] and I will take a look at it, but possibly it's not until next week that we have some sort of answer (bug, expected, workaround etc...). But I'm requesting similar hardware to confirm the problem in the meantime. I'll try to throw JankStats at it, and measure it and also whether JITting resolves it.

[Steve Bower [G]]

Hi - I ran a few tests with the CineToday3 perf app provided, on a Galaxy Watch 4. For me, I found there was some lag due to JIT'ing for the first 5-10 seconds if the profile rules had not been run, but after running the bg-dex-opt-job, that wasn't an issue, no discernible lag. Frame timings were ~11ms for the 50th percentile. I'll be in the office next week, so can try again with an older device like the one mentioned.

Also, I remembered a further detail about running bg-dexopt-job - the actual profile rules from the app are installed after the app has been installed and launched - so you have to wait about 1 minute after launching it before running adb shell cmd package bg-dexopt-job . Note that in future versions of Wear, the optimisation will be performed at installation time.

[bod]

Thanks a lot for looking into it!

[bod]

It's good to know and reassuring that at least on a recent device it's running fine. To be honest I wouldn't be too surprised if the only conclusion is that my device is just too old and not powerful enough. But curious to hear about your conclusions after you can test more.

[bod]

Speaking of performance, were there any interesting findings or followup on my issues above?

[Steve Bower [G]]

Hi - yes, I finally got my hands on a bluegill device and installed your test app on it (sorry for the lack of updates, there was a delay getting hold of a device and then I've been on vacation). Once the app was installed and optimised, it was solid and scrolled quite nicely. I saw an occasional frame missed when really flinging down the list, but overall it was very usable.

[bod]

Thanks for the update. Wow, I'm surprised by this, I have never achieved smoothness.

[bod]

I'll have to play with it again

[bod]

Oh yeah it's not perfect but a lot better than what can be seen on the video I posted earlier.

[Steve Bower [G]]

And it's even better on newer devices 🙂

[bod]

haha yes I can imagine!

[bod]

maybe my unit is due for a factory reset