https://kotlinlang.org logo
Channels
Powered by
#compose
Title
# compose
z

Zoltan Demant

02/17/2022, 9:06 AM
Is it possible to acheive release-compose-performance in a debug build, e.g. what are the properties that are required to make it happen, if possible? Id like to make my debug build similar but not exactly identical to the release one, but even with the same default properties, theres a huge performance gap between the two.
Apparently 
staging
works perfectly for this. Heres what I ended up doing in case anyone else finds it useful.
Copy code
buildTypes {
    debug {
        minifyEnabled false
        shrinkResources false
        signingConfig signingConfigs.debug
    }

    release {
        minifyEnabled true
        shrinkResources true
        signingConfig signingConfigs.release
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), '<http://proguard-rules.pro|proguard-rules.pro>'
    }

    staging {
        initWith release
        minifyEnabled false
        shrinkResources false
    }
}
s

Stylianos Gakis

02/17/2022, 3:31 PM
Copy code
minifyEnabled false
shrinkResources false
Both indicate this wouldn’t give you the performance boost you’d like to see though right? Because I’m guessing they override those properties initially taken from ‘release’. Is that not the case? Feels weird that this works for you.
➕ 1
z

Zoltan Demant

02/17/2022, 3:44 PM
I cant really explain it, but the performance boost is there (at least 90% of it) with these values set to false.
s

Stylianos Gakis

02/17/2022, 3:58 PM
I thought minifying is the big thing that makes this difference. I’d love for someone who knows to chime into this and explain tbh
z

Zoltan Demant

02/17/2022, 4:01 PM
I feel exactly the same way. The only thing that seems to make a difference performance wise is debug/release builds for me.
a

Adam Powell

02/17/2022, 4:20 PM
there are a few things that can change on the side of what compose does (generating live literals support code, for example) and a few things that can't (ART changes its JIT behavior based on whether the app is debuggable)
👌 1
👌🏽 1
if you have specific UIs/configurations that you're finding painful to work with in debug mode, please file an issue with a sample that reproduces it and we can see what knobs we can turn overall to help
👌🏽 1
👌 2
z

Zoltan Demant

02/17/2022, 4:40 PM
Thank you Adam! Honestly, almost everything is pretty sluggish for me when using debug builds. Animations stutter greatly, and many components take over 100 ms to render (it gets better the more they get rendered, but usually my tests too short for that to have an effect). Im only seeing about 5-10% increase in build time when using a staging/release build, and performance is perfect, so I really dont mind. My project is pretty huge, so Im not sure where Id even start to create a sample of it, and whether that would recreate the issues Im seeing.
c

Colton Idle

02/18/2022, 5:48 AM
For me, I mostly notice scrolling being janky in lists and especially in this one section where I have this local search/filtering being done. i.e. Type into a field and as you type it debounces and then filters the list. typing in there in debug builds is pretty attrocious, but when isDebuggagebl = false, it runs fine.
z

Zoltan Demant

02/18/2022, 9:01 AM
Not sure how related this is, but one huge drawback of using release builds while debugging is that windows locks the process about 75% of the time; requiring a clean & build to be able to run the app. Ive gone through all stackoverflow posts about this, and the underlying bug has been fixed in the latest release of IntelliJ - but in the meantime, are there any flags that sort of speed up debug builds, or is it all in the debuggable flag?
Powered by