Why is compose on android in release so much faste...

# compose

[ursus]

Why is compose on android in release so much faster?

Is it just R8 doing it's magic? Or are there some compose flags being flipped during release task as well? (Do they even exist?)

[ephemient]

https://github.com/androidx/androidx/blob/androidx-main/compose/runtime/runtime/proguard-rules.pro
in release, the proguard rules turn off tracking of debug info, which means a lot less bookkeeping for the compose runtime

[ursus]

hmm okay so no flags explicitly

just a rules file that allows R8 to optimize it a lot?

[jw]

It also means the VM isn't interpreting

[jw]

The debuggable flag turns off a lot of runtime perf stuff

[ursus]

what do you mean vm isnt interpreting? i.e. aot compilation?

[ursus]

the debuggable flag is that the one from android manifest? i.e general android?

should I try to toggle that somehow on compose multiplatform?

[Ben Trengrove [G]]

I wrote about this a while back
https://medium.com/androiddevelopers/why-should-you-always-test-compose-performance-in-release-4168dd0f2c71

[ursus]

Full disclosure 😀 I'm trying to speed up compose multiplatform/desktop (and I'm not seeing any go fast = true knobs in gradle

[ephemient]

debugging forces the VM to deoptimize any machine-compiled bytecode and use the interpreter to step through instead. I don't know the details of ART on whether it can start with AOT/JIT and then deopt only once a debugger is attached (as JVM does), but that's a pretty common issue among all VMs

[ursus]

“debugging” here means android manifest debuggable = true?

[ephemient]

setting compose { includeSourceInformation = false } might be similar to what R8 strips out

[ursus]

thats probably the core issue i dont understand — is this all ART specific? (the debuggability of an app) or general to any jvm-ish

[ursus]

okay so say in hotspot, this is all irrelevant, i,e, there is no debug/release distinction in jars in general, right?

[ephemient]

Android has a debuggable flag in the manifest. if an app is not debuggable, it's not possible to attach a debugger, and so ART is free to make optimizations. if an app is debuggable, then I'm not sure how much ART will optimize (and then deopt in case a debugger is attached at runtime).

[ephemient]

since JVM doesn't have that distinction (anything can have a debugger attached anytime), it does need a deopt path, but without a debugger attached, it should be optimized normally (after some number of runs… unless you use CDS)

[ursus]

okay so it doesn’t exist on jvm..thats what I needed to know

thank you!

[Konstantin Tskhovrebov]

if you have a reproducible example of a slow compose desktop app (but faster on android) then file an issue please with the project and we will investigate!

[ursus]

no no I'm fine, just wondering if I'm not noobishly leaving something like optimizations = false on and going to prod with it

thanks though

[jw]

Setting source information to false only affects your compilation unit. It does not affect libraries, and worst of all its present in places like remember so it gets inlined A LOT

[jw]

You can run R8 over your desktop app if you want the best Compose UI performance on the JVM (ignoring other optimizations like AppCDS and all the Project Leyden work)

[jw]

Hopefully someday JetBrains will support using R8 as a built in solution instead of ProGuard

[jw]

There's an issue for that, but I'm on mobile. It's not hard to find though. I'll link it later.

[ursus]

appcds supposedly has an issue with compose desktop -- but I'll try to get the R8 going, thank you!