Xavier,
Thanks for the information. We are coming to a point now where the decision
to switch our build process is coming to an end. We would really like to
move to gradle, hopefully you guys are able to get these optimizations in
soon. Once we make the decision, we are going to be stuck with it for a
while.
Where can i keep up to date with the exact changes that are going into each
build of the gradle plugin? I need to know when these changes are in place
as soon as possible.
Thanks
On Thursday, January 16, 2014 10:48:52 AM UTC-6, Xavier Ducrohet wrote:
>
> Right now each project will pre-dex its dependencies on its own. This
> means 2 components depending on the same library will both run pre-dex on
> that library's classes.jar which is silly. We're looking at fixing this.
>
> Another thing we are looking at is parallelization at the task level.
> Right now Gradle only supports it at the projects level. It'll build 2 sub
> projects in parallel (if there are no dependencies between the two), but in
> a single project it won't parallelize its task. We are working with the
> Gradle developers to change this.
>
> Of course the tasks themselves can do their work in parallel, and most of
> our tasks do already. Pre-dexing doesn't though, so if a project has more
> than one dependencies it'll run pre-dex one by one. This is fixed in the
> next Gradle version.
>
> We do take performance very seriously, but we also wanted to provide a lot
> of features and flexibility in our build. This means we do some extra work.
> For instance our resource merger is extra work that aapt does in a way but
> differently (more efficiently in some ways, less in others, but with much
> less flexibility). We are working to do more to optimize each task and, as
> I mentioned above, provide generic performance improvements as well.
>
> I'm a bit surprised your build went from 1:20 to only 0:58 when running
> assembleDebug vs build. 'build' does both debug and release but also runs
> lint. It should be a lot more work than just assembleDebug. Also, do you
> have flavors?
>
> One other thing to consider is incremental build. Pre-dexing for instance
> makes clean build clearly slower but incremental builds faster. The rest of
> the build is also very good at only doing what needs to be done and nothing
> extra, which Ant wasn't very good at.
>
> Disabling pre-dexing on all projects without touching each project's
> build.gradle doesn't seem to be easy. The issue is that doing (in the main
> build.gradle):
>
> subprojects {
> /// some config
> }
>
> this gets applied before all the other projects' own build.gradle are
> applied. So unless you can apply the 'android' or 'android-library' in
> there, you won't be able to use our DSL. I need to look into this.
>
>
> On Thu, Jan 16, 2014 at 6:51 AM, Ashton Cummings
> <[email protected]<javascript:>
> > wrote:
>
>> My Stack post <http://stackoverflow.com/q/21125302/427763>
>>
>> Using gradle 1.9-rc-3
>> When building with gradle on a multi-project setup containing roughly 140
>> projects/libraries, the build time took 1 hour and 22 minutes. And i was
>> using "--parallel". And our ANT build takes less than 20 minutes without
>> parallel building.
>>
>> Here is what i was initially doing:
>>
>> ./gradlew clean
>>> ./gradlew build --parallel
>>>
>>
>> This took 1 hour and 22 minutes, roughly. I did a little testing it seems
>> like the dexing is taking the longest amount of time. Is there a way to get
>> the gradle process to re-use the stuff it has already dexed? If the
>> libraries have already been built, it should re-use the already dexed
>> libraries.
>>
>> I saw the option --no-rebuild, but when i run with that option it says
>> the following:
>>
>>> File '/path/to/project/build/libs/project.aar' specified for property
>>> 'bundle' does not exist.
>>>
>>> I replaced the path and the project name with generic stuff.
>>
>> ***
>>
>> After some assistance i added "preDexLibraries = false" to all of my
>> "build.gradle" files. However, i still would like to know a centralize
>> place that i can put that entry and it affect all the other "build.gradle"
>> files. Because having to add that to all of the "build.gradle" files is
>> annoying and if i ever have to remove it, it will be more annoying. This
>> did not reduce the time to what we are needing.
>>
>> After some more assistance, i ran "assembleDebug" instead of "build".
>> This way it will only do debug builds instead of both release and debug.
>> This still did not bring us down to the time we are getting with ANT. With
>> all these changes we are only down to 58 minutes. And our ANT process is
>> less than 20 minutes. Our ANT process is what android provides only
>> modified to support large multi-project setups and to re-use dexed
>> libraries. The dex process in the gradle process is taking 1+ minute for
>> each project. It is by far the largest time consumer.
>>
>> ***
>>
>> So, how can we speed the process up more? Is gradle re-using the dexed
>> libraries after they have been dexed? What are your suggestions? For us to
>> move over to gradle, it has to be able to compete with the ANT process.
>>
>> Thanks
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "adt-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Xavier Ducrohet
> Android SDK Tech Lead
> Google Inc.
> http://developer.android.com | http://tools.android.com
>
> Please do not send me questions directly. Thanks!
>
--
You received this message because you are subscribed to the Google Groups
"adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
