https://github.com/facebookincubator/dataclassgenerate is Kotlin Data Class is really that bad for Android APK files?

It depends. At that scale when you can’t control the reuse of code and apps are so large, then maybe this is useful 🤷‍♂️

I also don't understand the "maybe the compiler won't know whether or not the object functions are used".

It depends. At that scale when you can’t control the reuse of code and apps are so large, then maybe this is useful 🤷‍♂️

100% agree Otherwise optimizing data classes looks like a premature optimization

It seems more work than just removing data and having the ide generate the equals and hashcode and to string for you if you are truly worried lol

At their scale, it makes sense - using data classes just for state means you might have a lot of generated toString/equals/copy that you are not using at all. So this can help reduce that generated overhead if you are not using it. But also, a lot of stuff facebook does is due to their scale - they have to support an insane number of devices while building up on years of legacy, hacks and mystery meat, so I wouldn’t really give too much attention to it.

Even small problems hit hard at scale. If the audience is interested project’s readme has links to public talks that give an idea of the problem scope at scale and an estimation of data classes residual overhead after optimisers

Nice, didn’t see those. Just noticed you’re one of the authors, seems like it was a pretty fun project, nice work 👍

It would be nice if the readme had rudimentary metrics that show the gains and trade offs.

Eh, that’s a quite wide question, since scale can mean different things and different things become concerns depending on your definition of it. I.e. FB has to cover a lot of markets and everyone is the target user, including low-end devices with slow processors, low storage and low amounts of RAM. They operate an all dimensions of scale. With hundreds of modules and a huge app, having just 10% size overhead might cause a huge drop in installs (it can be 10-20-30-300mb) difference. Since this is mostly a dex count optimisation, shaving just 10% off the final dex size can increase user acquisition by a small percentage, which is potentially worth millions of dollars in FB’s case. Compile time here is a smaller tradeoff (yes, it will impact it but caching + fresh builds are done on a CI) for the final app size reduction. It might also reduce your app’s startup time due to the multidex impact, since this way you can avoid it. But for some other apps, scale might mean performance optimisations - i.e. trading apps where speed is of critical importance, and there you might require some other optimisations that would try and “primitivize” data classes, due to the performance impact instatiation has. On some other apps, you might hit the problems of scale as in the amount of data, which requires different optimisation points and you gotta be careful of complexities. Meanwhile, somewhere you only care about a high-value target market and the scaling problem is more oriented on “how can the codebase scale for the amount of developers we have”. I’d suggest as a manager to find the biggest pain points that impact your app’s performance on different levels - your team’s performance (readability? build times?), your app’s performance (from startup to logic to UI) and user acquisition performance and your target market’s constraints (memory?speed?storage?data?), and then the calculation of “is it worth migrating” becomes way easier - time x money to implement vs time x money saved.

All I was looking for was something like described in the linked video. https://archive.fosdem.org/2022/schedule/event/dataclassgenerate_shrinking_kotlin_data_classes/

oh, sorry, thought your questions were more generic oriented