Skip to content
This repository has been archived by the owner on Apr 25, 2024. It is now read-only.

Improving DEXing process #88

Open
AdamClements opened this issue Apr 8, 2014 · 4 comments
Open

Improving DEXing process #88

AdamClements opened this issue Apr 8, 2014 · 4 comments

Comments

@AdamClements
Copy link
Contributor

ADT > 21 provides DexMerger to merge pre-dexed files, we aren't making use of this. This would kill a number of birds with one stone:

  • Incremental build times should improve as libraries and clojure core would be pre-dexed and simply merged in
  • DexMerger allows a CollisionPolicy of KEEP_FIRST rather than the dx default of FAIL, this allows a number of libraries which currently work on the jvm and fail on clojure to successfully build (the jvm policy is keep first) and removes the need for a number of project excludes
  • Building incrementally and merging should solve the problem a lot of people have running out of heap space while dexing for non-trivially sized projects.

Happy to collaborate on investigating this feature, but hesitant to take it all on myself.

@alexander-yakushev
Copy link
Contributor

Hi Adam,

I remember trying to make it work a year ago or so, when the feature was in beta(?) and only Eclipse was using it (not the standard Android toolchain). For some reason I didn't work for Clojure back then. Can you please put a link to some documentation for it?

@alexander-yakushev
Copy link
Contributor

Let's revisit this one and see what's changed.

  • Incremental dexing is already there without split DEX files. The downside is that it doesn't work in multi-dex projects.
  • Collision policy might be helpful, but then we don't know which classes of the duplicates actually get inside. For me it's better to fail when there are duplicates, and then micromanage dependencies manually.
  • How important is the heap overflow issue? 4GB is enough for me so far, could probably bump it up to 6GB if necessary.

@AdamClements
Copy link
Contributor Author

Travis only has 3.5GB memory, so I have to keep my dex process below 3gig really. I haven't really had any problems with that lately though. I get the feeling this isn't worth pursuing any more. We just need them to port incremental dexing to the multi-dex process.

@alexander-yakushev
Copy link
Contributor

OK. I'll leave this hanging in case the memory issue surfaces at 3-4GB, or until Google themselves improve the dex/multidex process somehow.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants