y

    yschimke

    3 months ago
    @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.
    b

    bod

    3 months ago
    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.
    y

    yschimke

    3 months ago
    It's exactly what you guessed
    Never run a debug build on a device for use
    Tgo1014

    Tgo1014

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

    bod

    3 months ago
    Good to hear. I'll try a release build soon 🙂
    Oh and yeah the current version has a Tile, and so planning the new one to have it too.
    Tgo1014

    Tgo1014

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

    bod

    3 months ago
    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. 😅
    (also it's badly cropped - I guess I should have used maxLines=1)
    Tgo1014

    Tgo1014

    3 months ago
    Can you scroll on a Tile? No right?
    b

    bod

    3 months ago
    that's a nope 🙂
    Tgo1014

    Tgo1014

    3 months ago
    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
    b

    bod

    3 months ago
    I think not but maybe there are ways around it
    y

    yschimke

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

    Ataul Munim

    3 months ago
    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?
    b

    bod

    3 months ago
    have you had a chance to look at the tiles material components alpha?
    Not yet!
    Well I finally tried my app with a release build. While it is definitely better I must say it is still very much slower than the View version. Even on a simple screen (a list), there is some jank. I will experiment with an even simpler list to compare. Granted my watch is a Fossil Q Explorist Gen 3, so and old model. But doesn't look good for Compose.
    y

    Yingding Wang

    3 months ago
    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

    Tgo1014

    3 months ago
    This happens to me, sometimes after a while it gets up to performance.
    y

    yschimke

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

    bod

    3 months ago
    👍 I'll investigate more.
    y

    yschimke

    3 months ago
    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.
    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.
    If it's a compose bug, in AS EE, you can see the composition counts to see whether it's doing too much work.
    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.
    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.
    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.
    b

    bod

    3 months ago
    thanks a lot for all the resource! I'll definitely dig 🙂
    y

    yschimke

    3 months ago
    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" 🙂
    b

    bod

    3 months ago
    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.
    (working on this evenings and week-ends however so won't be too reactive)
    y

    yschimke

    3 months ago
    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

    John Nichol

    3 months ago
    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
    On newer devices/builds the baseline profile optimization will run on app install.
    Tgo1014

    Tgo1014

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

    John Nichol

    3 months ago
    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
    The library has the profile
    and if you leave the device on change it will get applied
    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
    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
    b

    bod

    3 months ago
    thanks for the info! Interesting stuff.
    Steve Bower [G]

    Steve Bower [G]

    3 months ago
    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
    b

    bod

    3 months ago
    very cool, thanks!
    y

    Yingding Wang

    3 months ago
    @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]

    Steve Bower [G]

    3 months ago
    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.
    b

    bod

    3 months ago
    lol I've ran
    adb shell cmd package bg-dexopt-job
    15 minutes ago and it's still not over 😅
    Re: performance issues. I made a very simple app which is just a list of
    Chip
    . My device is a Fossil Q Explorist Gen 3 (bluegill). • Running the debug apk: extremely laggy, lots of dropped frames (expected) • Running the release apk: ◦ After running
    adb shell cmd package bg-dexopt-job
    and making sure it shows as
    speed-profile
    in dumpsys ◦ Less laggy but still not smooth, lots of dropped frames ◦ Definitely not as smooth as a RecyclerView (compare with the system menus in the video) ◦ Video here • Project is here (
    perf-tests
    branch) • Release apk is here
    y

    yschimke

    3 months ago
    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.
    @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]

    Steve Bower [G]

    3 months ago
    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.
    b

    bod

    3 months ago
    Thanks a lot for looking into it!
    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.
    Speaking of performance, were there any interesting findings or followup on my issues above?
    Steve Bower [G]

    Steve Bower [G]

    1 month ago
    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.
    b

    bod

    1 month ago
    Thanks for the update. Wow, I'm surprised by this, I have never achieved smoothness.
    I'll have to play with it again
    Oh yeah it's not perfect but a lot better than what can be seen on the video I posted earlier.
    Steve Bower [G]

    Steve Bower [G]

    1 month ago
    And it's even better on newer devices 🙂
    b

    bod

    1 month ago
    haha yes I can imagine!
    maybe my unit is due for a factory reset