Kotlinx.coroutines: Include dex counts (methods, fields, classes) in release notes, with comparison with recent versions

Created on 7 Sep 2018  Â·  3Comments  Â·  Source: Kotlin/kotlinx.coroutines

I noticed that since kotlinx.coroutines moved to Kotlin 1.2 experimental multiplatform, its size grew a bit in terms of methods count, going over 2K. On Android, each dex is limited to 65 536 methods, and same for field and classes, so libraries growing in size can sometimes be a concern (although multidex and proguard can often remove the issue without real drawbacks).

Consequently, it would be nice to have these metrics coming with each release so we know the un-proguarded size, and this would help ensure the library never becomes too big because of a great new feature that might add loads of methods, fields or classes.

There are ways to automate this in the build process. Also, there is this open source gradle plugin by KeepSafe (where I recommend to disable counting by default, to be only on demand, or when building releases or pre-releases).

Feel free to tell what you think, even if you don't think it's a good idea.

waiting for clarification

Most helpful comment

It also will vary wildly based on what you use and your settings of those
tools.

That being said, sanity checking these numbers to prevent a large
regression isn't a terrible thing. I don't think they need published
anywhere, but seeing how the counts vary from release to release can help
ensure the libraries contained in this project don't inadvertently balloon
in size.

On Fri, Feb 22, 2019, 9:41 AM Roman Elizarov <[email protected]
wrote:

Is this really needed? ProGuard/R8 is supposed to help by keeping only the
classes you actually use, so knowing the total number of methods/classes in
a library should not be needed, should it?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Kotlin/kotlinx.coroutines/issues/535#issuecomment-466418943,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEXCUZmIzP5Zj-wsz_G2CZDOeSxbhks5vQAGJgaJpZM4Wefuz
.

All 3 comments

Is this really needed? ProGuard/R8 is supposed to help by keeping only the classes you actually use, so knowing the total number of methods/classes in a library should not be needed, should it?

It also will vary wildly based on what you use and your settings of those
tools.

That being said, sanity checking these numbers to prevent a large
regression isn't a terrible thing. I don't think they need published
anywhere, but seeing how the counts vary from release to release can help
ensure the libraries contained in this project don't inadvertently balloon
in size.

On Fri, Feb 22, 2019, 9:41 AM Roman Elizarov <[email protected]
wrote:

Is this really needed? ProGuard/R8 is supposed to help by keeping only the
classes you actually use, so knowing the total number of methods/classes in
a library should not be needed, should it?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Kotlin/kotlinx.coroutines/issues/535#issuecomment-466418943,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEXCUZmIzP5Zj-wsz_G2CZDOeSxbhks5vQAGJgaJpZM4Wefuz
.

Closing this one. We will not be publishing dex counts, but we are considering tracking some kind of "additional size after R8" for some set of sample projects that use coroutines (vs similar code without coroutines)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mhernand40 picture mhernand40  Â·  3Comments

ddeya picture ddeya  Â·  3Comments

IgorKey picture IgorKey  Â·  3Comments

sky87 picture sky87  Â·  3Comments

mttmllns picture mttmllns  Â·  3Comments