<https://github.com/facebookincubator/dataclassgen...
# android
i
https://github.com/facebookincubator/dataclassgenerate is Kotlin Data Class is really that bad for Android APK files?
šŸ˜² 2
šŸ‘ 1
a
It depends. At that scale when you canā€™t control the reuse of code and apps are so large, then maybe this is useful šŸ¤·ā€ā™‚ļø
Then maybe donā€™t use data classes if you are worried about it
b
I also don't understand the "maybe the compiler won't know whether or not the object functions are used".
šŸ˜„ 1
a
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
a
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
i
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.
s
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
i
Nice, didnā€™t see those. Just noticed youā€™re one of the authors, seems like it was a pretty fun project, nice work šŸ‘
ā¤ļø 1
b
It would be nice if the readme had rudimentary metrics that show the gains and trade offs.
Marking a class as
data
is built-in, trivial, and simple. At what scale does performance become a concern? What is the compile time and run time benefits of implementing this alternate workflow? If I'm a tech manager, what can I use to make a determination that this would be worth the time and effort to migrate?
i
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.
b
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/
Where there is a simple byte-code comparison that declares a 60% reduction in bytecode generation. That's a pretty significant number and adds a tremendous amount of weight to the uptake of this process.
i
oh, sorry, thought your questions were more generic oriented