6 ms·

A coworker mentioned that multidexing also take ages and uses huge amounts of memory.

by throwawayish 10y ago

d33 10y ago
Are there any legitimate use cases for that many methods?
- taormina 10y ago
  I mean, it means you can't pull in Scala. I mean, you can, but pull in enough bloated Java 3rd party libraries and you might be hitting that limit pretty quickly. Google broke Google Play Services out into a large number of small dependencies once they were past the 15k method mark. Mind you, certain compilation settings will totally strip out unused methods, but it's still annoying.
- kelnos 10y ago
  IIRC the Facebook app had many more than that at one point, and had to use multi-dexing. Not sure if that's still the case. I've also heard that scala apps on Android can sometimes hit the limit, because pulling in the scala stdlib greatly bloats the method count.
  - Cyph0n 10y ago
    Wasn't that the initial reason behind splitting off Messenger into a separate app?
    - kelnos 10y ago
      I don't know, but I would doubt it. Making such a huge product decision based on an engineering limitation (that has a workaround) seems like a poor idea.
- Exuma 10y ago
  Ad SDK's have tons of methods.
- BoorishBears 10y ago
  It sounds like a ridiculous number of methods until you realize just importing Guava brings in 20k methods, using half the Amazon SDKs would probably bring another 20k-40k, Apache's main utils bring about 10-20k, etc.
- jayd16 10y ago
  For example, the amazon sdk jar has 40,000 alone or something insane. You can hit if you're using a few large libraries. That said, you can use proguard to strip your unused methods and it usually fine even for large applications.
- ungzd 10y ago
  Because of "single responsibility principle" it's better if classes and methods do one thing. That usually leads to lots of small classes and small methods.
- vkou 10y ago
  Java's crippled generics, lack of tuple support, and lack of default parameters encourage interface bloat in utility libraries. Given how bloody good Java IDEs are (By which I mean to say - how good IntelliJ is), the cognitive cost of this interface bloat is very low... Until you start developing for Android.
  - monocasa 10y ago
    Wouldn't Java's crippled generics actually help reduce the method count since due to type erasure they're all the same method at the VM level anyway?
    - Matthias247 10y ago
      For reference types probably yes, but Java also often needs extra methods or overloads for handling primitive types, which would get unnecessarily boxed when used in generic methods.
    - josefx 10y ago
      On the one hand yes, on the other hand Java also generates Bridge methods when you implement a generic interface. A MyType implementing Comparable<MyType> will contain a compareTo( MyType ) method and a generated compareTo( Comparable ) bridge method. It is more likely that generated classes, countless getters and setters and a tendency to small methods has a higher impact.
Benjammer 10y ago
Why do people always talk about multidexing like it's such a nightmare? https://developer.android.com/studio/build/multidex.html https://developer.android.com/studio/build/multidex.html It's really not that bad, It only gets a little squirrely if you're trying to support super old android versions.
- karmelapple 10y ago
  Our app's build time ballooned by 2-3X or more when we went to multidex. We've had some luck reducing it, but we'd still like to axe multidex. I definitely consider a 3X build time increase (not 30 seconds to 90 seconds, but 1 or 2 min to 5-8) to be a significant problem, bordering on nightmare... especially since we just included a few more libraries that put us past the 65k mark. Is that what other people have seen?
  - dgfgfdagasdfgfa 10y ago
    Surely that's just a release build, though...? How would this bottleneck productivity for a team?
    - orbitur 10y ago
      When you deploy release-like builds to your QA team (as you should), a tripled-build time is a bit problematic if you're trying to iterate quickly.
      - Benjammer 10y ago
        Who needs to "iterate" so quickly that several minutes added to your build time becomes a huge issue?
        BoorishBears 10y ago
        Me? I work on embedded android installations that have over a thousand years combined of running with 0 software crashes. Once I get to a certain point in developing an app for our installations I start profiling for the slightest memory leaks by watching changes in memory usage profiles for different user flows. And I can only do that with release builds if I want useful numbers. I've had us split up apps over build times because of Multidex (for example, most of our AWS centric code lives in a separate app that exposes specific functions via an AIDL interface because the SDK was bringing in too many methods)

A coworker mentioned that multidexing also take ages and uses huge amounts of memory.

d33 10y ago

Are there any legitimate use cases for that many methods?

taormina 10y ago
I mean, it means you can't pull in Scala. I mean, you can, but pull in enough bloated Java 3rd party libraries and you might be hitting that limit pretty quickly. Google broke Google Play Services out into a large number of small dependencies once they were past the 15k method mark. Mind you, certain compilation settings will totally strip out unused methods, but it's still annoying.
kelnos 10y ago
IIRC the Facebook app had many more than that at one point, and had to use multi-dexing. Not sure if that's still the case. I've also heard that scala apps on Android can sometimes hit the limit, because pulling in the scala stdlib greatly bloats the method count.
- Cyph0n 10y ago
  Wasn't that the initial reason behind splitting off Messenger into a separate app?
  - kelnos 10y ago
    I don't know, but I would doubt it. Making such a huge product decision based on an engineering limitation (that has a workaround) seems like a poor idea.
Exuma 10y ago
Ad SDK's have tons of methods.
BoorishBears 10y ago
It sounds like a ridiculous number of methods until you realize just importing Guava brings in 20k methods, using half the Amazon SDKs would probably bring another 20k-40k, Apache's main utils bring about 10-20k, etc.
jayd16 10y ago
For example, the amazon sdk jar has 40,000 alone or something insane. You can hit if you're using a few large libraries. That said, you can use proguard to strip your unused methods and it usually fine even for large applications.
ungzd 10y ago
Because of "single responsibility principle" it's better if classes and methods do one thing. That usually leads to lots of small classes and small methods.
vkou 10y ago
Java's crippled generics, lack of tuple support, and lack of default parameters encourage interface bloat in utility libraries. Given how bloody good Java IDEs are (By which I mean to say - how good IntelliJ is), the cognitive cost of this interface bloat is very low... Until you start developing for Android.
- monocasa 10y ago
  Wouldn't Java's crippled generics actually help reduce the method count since due to type erasure they're all the same method at the VM level anyway?
  - Matthias247 10y ago
    For reference types probably yes, but Java also often needs extra methods or overloads for handling primitive types, which would get unnecessarily boxed when used in generic methods.
  - josefx 10y ago
    On the one hand yes, on the other hand Java also generates Bridge methods when you implement a generic interface. A MyType implementing Comparable<MyType> will contain a compareTo( MyType ) method and a generated compareTo( Comparable ) bridge method. It is more likely that generated classes, countless getters and setters and a tendency to small methods has a higher impact.

Benjammer 10y ago

Why do people always talk about multidexing like it's such a nightmare? https://developer.android.com/studio/build/multidex.html https://developer.android.com/studio/build/multidex.html It's really not that bad, It only gets a little squirrely if you're trying to support super old android versions.

karmelapple 10y ago
Our app's build time ballooned by 2-3X or more when we went to multidex. We've had some luck reducing it, but we'd still like to axe multidex. I definitely consider a 3X build time increase (not 30 seconds to 90 seconds, but 1 or 2 min to 5-8) to be a significant problem, bordering on nightmare... especially since we just included a few more libraries that put us past the 65k mark. Is that what other people have seen?
- dgfgfdagasdfgfa 10y ago
  Surely that's just a release build, though...? How would this bottleneck productivity for a team?
  - orbitur 10y ago
    When you deploy release-like builds to your QA team (as you should), a tripled-build time is a bit problematic if you're trying to iterate quickly.
    - Benjammer 10y ago
      Who needs to "iterate" so quickly that several minutes added to your build time becomes a huge issue?
      - BoorishBears 10y ago
        Me? I work on embedded android installations that have over a thousand years combined of running with 0 software crashes. Once I get to a certain point in developing an app for our installations I start profiling for the slightest memory leaks by watching changes in memory usage profiles for different user flows. And I can only do that with release builds if I want useful numbers. I've had us split up apps over build times because of Multidex (for example, most of our AWS centric code lives in a separate app that exposes specific functions via an AIDL interface because the SDK was bringing in too many methods)