8 ms·

Everytime I tried to switch to Android Studio from Eclipse I switched back because of how incredibly slow AS's build time is. Eclipse builds and deploys my app

Everytime I tried to switch to Android Studio from Eclipse I switched back because of how incredibly slow AS's build time is. Eclipse builds and deploys my app in seconds, AS takes at least half a minute. I tried all the tricks I can find on SO, etc. without success.

mikestew 11y ago
And $DEITY help you if you've fiddled with build.gradle. "Please wait five minutes while I go resync a bunch of stuff because you changed a variable name in your build file."
- dave2000 11y ago
  We use gradle at work with c++ projects. It's hilarious how slow it is. Why do people use it?
  - MaulingMonkey 11y ago
    Because it's faster than ANT. (Used it via nVidia CodeWorks for Android when doing a mostly C++ project which also had some Java in it for Android.)
    - dave2000 11y ago
      What's wrong with just using a makefile?
      - deleted 11y ago
        [deleted]
      - MaulingMonkey 11y ago
        1) You're stepping outside of the boundaries of what every 3rd party API documents configuring ('add this to your gradle config') when I'm already too much of a bottleneck for figuring out build configuration. 2) You're replacing something that... mostly works out of the box, with something you have to configure entirely yourself. 3) Requires intimate knowledge of the entire Android build chain to properly set up. I might know about ~90% of it after some nasty debugging sessions involving flaky USB connections and commands which return 'successfull' exit codes / stdout spam when they fail - so we'll call the bus factor of that setup 0.9 as my coworkers frankly did not want to know, for which I don't even remotely blame them. 4) Yet another build dependency to install on every dev and build machine (make. *nix isn't an answer either: too many Windows specific toolchains for gamedev to make non-Windows remotely feasible as a primary dev environment.) 5) Not actually solving the remaining bottlenecks. Switching to Gradle got us down to ~5 seconds / build / project for the Java and APK packaging portion of the build, which looked mostly like it was dependency scanning, zipping, and code signing - just like I'd need my Makefile to be doing anyways. I was skeptical that I could do much better. Next, I switched linkers and saved closer to 90 seconds / build / project for even the simplest typo fix in the C++ side of things. And that's just what's wrong with replacing gradle with a makefile. If we wanted to replace the entire build pipeline and build our C++ with makefiles too: 6) Would need to replace extensive existing MSBuild configurations entirely, or duplicate work between two different build setups. Would need to learn other platform build chains sufficiently as well (XB1, PS4, Win8 Apps... I don't recall seeing full docs on this when I still had access, although over the years I pieced together a distressingly large chunk of the pie. We'll optimistically call it 70% of the pie, for a bus factor of 0.7.) 8) Even with dependency files and substitution magic, make will rebuild more than VS with the right settings. I've also only ever done it with GCC - trying to figure out how to coax a proper dependency file out of MSVC's compiler doesn't sound fun. Mixing and matching compilers sounds like an even worse idea - a great way to introduce subtle rebuild bugs due to built-in #define differences. No, I'm not going to try and target XB1 with clang. 9) Poorer VS integration. Simple things like Ctrl+F7ing to compile / syntax check single files won't work without setting up your own keybindings to (ab)use e.g. "External Commands". That might be most of what's wrong for my use cases.
    - smrtinsert 11y ago
      This is a laughable generalization.
      - MaulingMonkey 11y ago
        In response to a similarly laughable generalization, with added parentheticals explaining the rather specific case I found this to be true within.
  - bpodgursky 11y ago
    In my extremely biased opinion... because it lets you do terrible things in free-form code which opinionated tools like Maven don't allow. (I'm not a fan)
  - smrtinsert 11y ago
    In a about a day of building with gradle, I could have manually downloaded and verified myself every jar my project will need, as compared to say, ant. The amount of time I lose to it is criminal especially considering it is supposed to improve our productivity. Gradle is a horrible thing that lets people do whatever they want - and people who think freedom == productivity flock to it for that reason only. History of course teaches otherwise.
  - on_and_off 11y ago
    I use gradle for Android projects. We replaced ant with gradle when we switched to Android studio. How to import a library with some resources with ant ? -copy paste it somewhere accessible in your project. It makes importing and more importantly updating the support lib (or most libs really) a pain in the ass. How does it work with gradle ? compile "com.android.support:appcompat-v7:23.2" Between this and flavors, I might not love gradle, but it is still a big step up from ant.
vdfs 11y ago
The first build is slow, but the later ones are faster as Android Studio use gardle daemon to speedup the build time
- chinhodado 11y ago
  It's not just the first build, the later ones are slow for me as well. Eclipse's first build (e.g. after you do a Clean project) is also slow but after that it's very fast.
  - twism 11y ago
    are you using wildcards (eg. com.foo:bar:1.3.+) in you deps in gradle? it forces gradle to look to the internet every time you build (unless you've checked "Work Offline")
    - portugee 11y ago
      Actually using dynamic versions (i.e. 1.3.+) are cached for 24 hours (unless you override the default). So you typically just pay the penalty for looking for new versions once a day.
whatever_dude 11y ago
I find AS to be much faster, more solid and stable than Eclipse in every aspect. I've been using AS for a couple of years, and was on Eclipse for about 4 years before that. With that said, your mileage may vary: Android Studio is one of those applications that seem to misbehave under certain specific conditions. Namely, if your main OS drive is not a SSD, things seem to slow down to a crawl.
- usrusr 11y ago
  Eclipse defaults to keeping all your tabs open, while AS defaults to aggressive LRU pruning? Eclipse always working hard to keep a live updated and as complete as possible bytecode model of your latest ctrl+s version available for instant (or close to instant) whole workspace error reporting, where AS only uses the compiler as a better linter, deferring non-local effects of code changes to the next gradle run, where errors are not even clickable in the console? The output of the IDE-internal "lint"-compiler run not even being available for a simple, local unit test rerun? Compared to the ambitious, smalltalk-derived vision of eclipse, AS sometimes feels like a glorified text editor that is only faster because it does not even try to do things eclipse does without much of a sweat. Now for some perspective, i know i have a rather biased view in this: i came to AS from eclipse when switching from backend to android (still do my backend stuff in eclipse), so i am not tainted by the supposedly terrible quality of eclipse-based android tooling that came before AS. Also, i am highly suspect of subconsciously blaming the IDE for certain annoyances that actually are just extra stuff that any tooling would have to do for android dev. I never used full IntelliJ, so i am only talking about AS in the strictest sense and do assume that regular IntelliJ can be closer to eclipse in terms of direct compiler integration and even build tool builds will not only be much more flexible than the gradle guiderails in AS but also less heavyweight (i guess i'm only talking about the gradle android plugin in this part). Now as AS2 claims to turn things upside down, i'd be glad to forget all this.
rcheu 11y ago
I'll second that Android Studio has absurdly slow builds times. It's not pretty common to have 2+ minute build times, and I'm using a MBPr mid 2015. I actually asked an Android frameworks engineer about this, and it seems like this is not an uncommon problem. The instant run in AS2 helps a lot, but without it, build times are unbearable.
xentred 11y ago
Exactly this. Even "Instant Run" has often been slower for me than an Eclipse run. Since I don't have a Core i7 with 16Gb of RAM, I stick with Eclipse for Android dev. I'm using Andmore (fork of Google's deprecated ADT plugin). I still use Gradle for the build configuration, but using the Gradle Eclipse AAR plugin (https://github.com/ksoichiro/gradle-eclipse-aar-plugin https://github.com/ksoichiro/gradle-eclipse-aar-plugin) I can simply edit the build.gradle file, run "gradle generateEclipseDependencies", and then import the generated Eclipse projects. Bonus being that I can "gradle assembleRelease" my app.

mikestew 11y ago

And $DEITY help you if you've fiddled with build.gradle. "Please wait five minutes while I go resync a bunch of stuff because you changed a variable name in your build file."

dave2000 11y ago
We use gradle at work with c++ projects. It's hilarious how slow it is. Why do people use it?
- MaulingMonkey 11y ago
  Because it's faster than ANT. (Used it via nVidia CodeWorks for Android when doing a mostly C++ project which also had some Java in it for Android.)
  - dave2000 11y ago
    What's wrong with just using a makefile?
    - deleted 11y ago
      [deleted]
    - MaulingMonkey 11y ago
      1) You're stepping outside of the boundaries of what every 3rd party API documents configuring ('add this to your gradle config') when I'm already too much of a bottleneck for figuring out build configuration. 2) You're replacing something that... mostly works out of the box, with something you have to configure entirely yourself. 3) Requires intimate knowledge of the entire Android build chain to properly set up. I might know about ~90% of it after some nasty debugging sessions involving flaky USB connections and commands which return 'successfull' exit codes / stdout spam when they fail - so we'll call the bus factor of that setup 0.9 as my coworkers frankly did not want to know, for which I don't even remotely blame them. 4) Yet another build dependency to install on every dev and build machine (make. *nix isn't an answer either: too many Windows specific toolchains for gamedev to make non-Windows remotely feasible as a primary dev environment.) 5) Not actually solving the remaining bottlenecks. Switching to Gradle got us down to ~5 seconds / build / project for the Java and APK packaging portion of the build, which looked mostly like it was dependency scanning, zipping, and code signing - just like I'd need my Makefile to be doing anyways. I was skeptical that I could do much better. Next, I switched linkers and saved closer to 90 seconds / build / project for even the simplest typo fix in the C++ side of things. And that's just what's wrong with replacing gradle with a makefile. If we wanted to replace the entire build pipeline and build our C++ with makefiles too: 6) Would need to replace extensive existing MSBuild configurations entirely, or duplicate work between two different build setups. Would need to learn other platform build chains sufficiently as well (XB1, PS4, Win8 Apps... I don't recall seeing full docs on this when I still had access, although over the years I pieced together a distressingly large chunk of the pie. We'll optimistically call it 70% of the pie, for a bus factor of 0.7.) 8) Even with dependency files and substitution magic, make will rebuild more than VS with the right settings. I've also only ever done it with GCC - trying to figure out how to coax a proper dependency file out of MSVC's compiler doesn't sound fun. Mixing and matching compilers sounds like an even worse idea - a great way to introduce subtle rebuild bugs due to built-in #define differences. No, I'm not going to try and target XB1 with clang. 9) Poorer VS integration. Simple things like Ctrl+F7ing to compile / syntax check single files won't work without setting up your own keybindings to (ab)use e.g. "External Commands". That might be most of what's wrong for my use cases.
  - smrtinsert 11y ago
    This is a laughable generalization.
    - MaulingMonkey 11y ago
      In response to a similarly laughable generalization, with added parentheticals explaining the rather specific case I found this to be true within.
- bpodgursky 11y ago
  In my extremely biased opinion... because it lets you do terrible things in free-form code which opinionated tools like Maven don't allow. (I'm not a fan)
- smrtinsert 11y ago
  In a about a day of building with gradle, I could have manually downloaded and verified myself every jar my project will need, as compared to say, ant. The amount of time I lose to it is criminal especially considering it is supposed to improve our productivity. Gradle is a horrible thing that lets people do whatever they want - and people who think freedom == productivity flock to it for that reason only. History of course teaches otherwise.
- on_and_off 11y ago
  I use gradle for Android projects. We replaced ant with gradle when we switched to Android studio. How to import a library with some resources with ant ? -copy paste it somewhere accessible in your project. It makes importing and more importantly updating the support lib (or most libs really) a pain in the ass. How does it work with gradle ? compile "com.android.support:appcompat-v7:23.2" Between this and flavors, I might not love gradle, but it is still a big step up from ant.

vdfs 11y ago

The first build is slow, but the later ones are faster as Android Studio use gardle daemon to speedup the build time

chinhodado 11y ago
It's not just the first build, the later ones are slow for me as well. Eclipse's first build (e.g. after you do a Clean project) is also slow but after that it's very fast.
- twism 11y ago
  are you using wildcards (eg. com.foo:bar:1.3.+) in you deps in gradle? it forces gradle to look to the internet every time you build (unless you've checked "Work Offline")
  - portugee 11y ago
    Actually using dynamic versions (i.e. 1.3.+) are cached for 24 hours (unless you override the default). So you typically just pay the penalty for looking for new versions once a day.

whatever_dude 11y ago

I find AS to be much faster, more solid and stable than Eclipse in every aspect. I've been using AS for a couple of years, and was on Eclipse for about 4 years before that. With that said, your mileage may vary: Android Studio is one of those applications that seem to misbehave under certain specific conditions. Namely, if your main OS drive is not a SSD, things seem to slow down to a crawl.

usrusr 11y ago
Eclipse defaults to keeping all your tabs open, while AS defaults to aggressive LRU pruning? Eclipse always working hard to keep a live updated and as complete as possible bytecode model of your latest ctrl+s version available for instant (or close to instant) whole workspace error reporting, where AS only uses the compiler as a better linter, deferring non-local effects of code changes to the next gradle run, where errors are not even clickable in the console? The output of the IDE-internal "lint"-compiler run not even being available for a simple, local unit test rerun? Compared to the ambitious, smalltalk-derived vision of eclipse, AS sometimes feels like a glorified text editor that is only faster because it does not even try to do things eclipse does without much of a sweat. Now for some perspective, i know i have a rather biased view in this: i came to AS from eclipse when switching from backend to android (still do my backend stuff in eclipse), so i am not tainted by the supposedly terrible quality of eclipse-based android tooling that came before AS. Also, i am highly suspect of subconsciously blaming the IDE for certain annoyances that actually are just extra stuff that any tooling would have to do for android dev. I never used full IntelliJ, so i am only talking about AS in the strictest sense and do assume that regular IntelliJ can be closer to eclipse in terms of direct compiler integration and even build tool builds will not only be much more flexible than the gradle guiderails in AS but also less heavyweight (i guess i'm only talking about the gradle android plugin in this part). Now as AS2 claims to turn things upside down, i'd be glad to forget all this.

rcheu 11y ago

I'll second that Android Studio has absurdly slow builds times. It's not pretty common to have 2+ minute build times, and I'm using a MBPr mid 2015. I actually asked an Android frameworks engineer about this, and it seems like this is not an uncommon problem. The instant run in AS2 helps a lot, but without it, build times are unbearable.

xentred 11y ago

Exactly this. Even "Instant Run" has often been slower for me than an Eclipse run. Since I don't have a Core i7 with 16Gb of RAM, I stick with Eclipse for Android dev. I'm using Andmore (fork of Google's deprecated ADT plugin). I still use Gradle for the build configuration, but using the Gradle Eclipse AAR plugin (https://github.com/ksoichiro/gradle-eclipse-aar-plugin https://github.com/ksoichiro/gradle-eclipse-aar-plugin) I can simply edit the build.gradle file, run "gradle generateEclipseDependencies", and then import the generated Eclipse projects. Bonus being that I can "gradle assembleRelease" my app.