57

right now we are in a situation of having build times 2 minutes 30 seconds for very simple change. This (compared to ANT) is amazingly slow and is killing the productivity of the whole team. I am using Android Studio and using the "Use local gradle distribution". I've tried to give more memory to gradle:

org.gradle.jvmargs=-Xmx6096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

A lot more memory. AND IT IS STILL GIVING ERRORS FOR MEMORY from time to time.

Exception in thread "pool-1-thread-1" java.lang.OutOfMemoryError: GC overhead limit exceeded

Amazing. I am using the parallel option and daemon:

org.gradle.parallel=true

org.gradle.daemon=true

It doesn't really help.

I've put the aforementioned parameters in ~/.gradle/gradle.properties (and I even doubted that Android studio is ignoring that, so I tested - it is not ignoring it).

Still from terminal I get 1:30 build time vs 2:30 in Android Studio, so not sure what is wrong there. 1:30 is STILL CRAZY compared to Ant. If you know what Android Studio is doing (or ignoring, or rewriting as gradle config), I'd be grateful to know.

So just CMD + B (simple compile) is super fast after changes, like 7 seconds. But when it comes to running the app, it starts the task dexXxxDebug, which is just killing us. I've tried putting 

dexOptions {
    preDexLibraries = false
}

Doesn't help.

I understand that gradle is probably still not ready for production environments, but I'm starting to regret our decision to move so early to it. We have lots of modules, which is probably part of the problem, but that was not an issue with Ant.

Any help appreciated, Dan

Some more information about execution times:

Description Duration

Total Build Time    1m36.57s
Startup 0.544s
Settings and BuildSrc   0.026s
Loading Projects    0.027s
Configuring Projects    0.889s
Task Execution  1m36.70s

The time eater: :app:dexDebug 1m16.46s

Danail
  • 10,443
  • 12
  • 54
  • 76
  • When you're doing Cmd-B builds from the IDE, it's not doing a full build going all the way to an APK -- that's why it's so much slower when you go to run, because there it's making a full APK and it's doing dex, which can take a long time. Have a look at this thread on the adt-dev mailing list which discusses build times https://groups.google.com/forum/#!topic/adt-dev/a-zmpJ6yCuI and gather the information discussed there and augment your question to see if we can shed any more light on it. – Scott Barta Jul 28 '14 at 23:48
  • 2
    I know it is just compiling the source, without building the dex. But how was Ant able to cope with this task for under 20 seconds, and I need about 2.5 minutes here? – Danail Jul 28 '14 at 23:50
  • 1
    It's a good question, but if you can gather some more information I won't have to make so many bad guesses ;) – Scott Barta Jul 28 '14 at 23:51
  • Information about times added to the question. – Danail Jul 29 '14 at 00:00
  • As I said, running Gradle from console is faster. Any information about the difference between Android Studio and running gradle directly is also appreciated. – Danail Jul 29 '14 at 00:01
  • 1
    Does this help? https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ – Scott Barta Jul 29 '14 at 00:08
  • This helps A LOT. From 2.5/1.5 minutes to 37-40 seconds. Thank you! I'd like to see if we can optimize further. If you post your comment as answer, I'll upvote (and probably accept it after collecting other answers). – Danail Jul 29 '14 at 00:20
  • See https://stackoverflow.com/questions/17324849/android-studio-gradle-build-speed-up -- scroll to the most recent answers – Mr-IDE Jun 27 '17 at 09:06

5 Answers5

136

I'm not quite sure why Android Studio is slower than the command line, but you can speed up your builds by turning on incremental dexing. In your module's build file, add this option to your android block:

dexOptions {
    incremental true
}

In that dexOptions block you can also specify the heap size for the dex process, for example:

dexOptions {
    incremental true
    javaMaxHeapSize "4g"
}

These options are taken from a thread on the adt-dev mailing list (https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ) which has a little more context.

Scott Barta
  • 79,344
  • 24
  • 180
  • 163
  • 2
    The javaMaxHeapSize helped me a lot when compiling the code (reduced my compile time from over 1 min to 19 sec) but haven't try the incremental option before - will try it later. – Simon Sep 16 '15 at 07:27
  • can anyone explain what's that "4g" means – Kamalakannan J Nov 17 '15 at 06:17
  • @sincerekamal 4g as in 4GB of memory. the docs are here - http://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.DexOptions.html#com.android.build.gradle.internal.dsl.DexOptions:javaMaxHeapSize – Abhijit Nov 18 '15 at 17:26
  • adding 'incremental true' along with 'javaMaxHeapSize "2g"' solved it for me – Dmitrii Jul 13 '16 at 09:41
  • WARNING: DSL element 'DexOptions.incremental' is obsolete and will be removed at the end of 2018. – The Dude Jul 03 '19 at 14:08
12

Our team was facing the same issue. Our project exceeds the method limit for dex(>65k). So, in out library project we put below options in build.gradle:

dexOptions {
    jumboMode = true
    preDexLibraries = false
}

In our project build.gradle:

 dexOptions {
    jumboMode = true
//  incremental true
}

previously we had incremental true. after commenting it its taking around 20s to run as compared to 2mins 30 seconds. I don't know this may solve your problem. but it can help to others. :)

vikoo
  • 2,451
  • 20
  • 27
1

Disclaimer: This isn't a solution - it's a statement that there is no solution with relevant link sources to prove it.

Since all answers here do not solve a problem that has been lingering since 2014, I'm gonna go ahead and post a couple of links which describe a very simillar problem and present OS-specific tweaks that might or might not help, since OP did not seem to specify it, and solutions vary a lot across them.

First is the actual AOSP bug-tracker issue referring to parallelization, with a lot of relevant stuff, still open and still with a lot of people complaining as off version 2.2.1. I like the guy who notes the issue (a high-priotity one at that) id including "666" not being a coincidence. The way most people describe music programs and mouse movement stuttering during builds feels like looking into a mirror...

You should note people report good stuff with process lasso for Windows, while I see none really reporting anything good with renice'ing or cpu-limiting in *nix variants.

This guy (who states he doesn't use gradle) actually presents some very nice stuff in Ask Ubuntu, that unfortunately doesn't work in my case.

Here is another alternative that limits threads of gradle execution, but that didn't really improve in my scenario probably due to what somebody says on another link about studio spawning multiple gradle instances (while the parameter only affects one instance's parallelism).

Note that this all goes back to the original "666", high-priority issue...

Personally I couldn't test many of the solutions because I work on a managed (no root privs) Ubuntu machine and can't apt-get/renice, but I can tell you I have an i7-4770, 8GB RAM and a hybrid SSD, and I have this problem even after a lot of memory and gradle tweaks over the years. It is a tantalizing issue, and I can't understand how Google hasn't committed the necessary human resources to the gradle project to fix something that is at the core of development for the most important platform they build.

One thing to note on my environment is: I work in a multi-dependency studio project, with about 10 subprojects, all of them building on their own and filling up the gradle pipeline.

Community
  • 1
  • 1
leRobot
  • 1,497
  • 1
  • 18
  • 30
  • 1
    Of course all of this is subjective, since a lot of people are working around the issue with jumbo mode and incremental, but that is their scenario. One thing to note is most builds take a lot the first time even with those (in my case) but will be better the next 2 or 3 times after that (7-30 second builds) This is mostly because of optimizations in studio 2.x. But I find that any form of clean-sync-build-run still presents the same 2-10 minute, high-system lockup rate that takes away 10% of my working day. – leRobot Aug 04 '16 at 10:37
0

When passing a value, you can append the letter 'k' to indicate kilobytes, 'm' to indicate megabytes, or 'g' to indicate gigabytes.

Manikandan K
  • 911
  • 9
  • 21
-3

'--offline' solved my problem.

Aziz Altun
  • 1