Tested on a 3.2 GHZ Quad Core machine with 4GB DDR3L, running GWT with the following commands takes a very long time:
First
mvn gwt:devmode
Second
mvn war:exploded
2-3 minutes for running dev mode, and another few minutes for compilation starts in the browser. It's almost 5 minutes for every run and test.
What Maven configuration could work to make the GWT compilation faster?
First you can set it to build for one browser only. Add this to the modules '.gwt.xml' file:
<set-property name="user.agent" value="gecko1_8"/>
(Other user agents can be found here https://gwt.googlesource.com/gwt/+/master/user/src/com/google/gwt/useragent/UserAgent.gwt.xml)
Another optimisation is to let gwt use more than one core when building. When you 'GWT Compile', on the advanced under 'Additional compiler options' add:
-localWorkers -8
Or the amount of thread you want to use.
Lastly, if your project contains multiple modules, each with their own entry points. You do not have to rebuild each one of them every time. Only the one you are working on. I have a project with 15+ modules and only build one at a time unless I have made a change to shared data in another module.
It's just as easy to remove modules from the 'GWT Compile' as it is to add them.
With the above being used you will get a build time of between 5 and 15 seconds.
Related
My Windows 7 machine has a quad core i7 processor. When I Rebuild my project, it takes on average 25 seconds. And when I launch the app, it takes on average 36 seconds (before the app is uploaded to the device).
I have 588 files in my project's /src folder, which includes all of my java and xml code. I've got two .so libs each 5MB and 7 jars in my /libs folder.
See my attached screenshot. As you can see my CPU is maxed out at 100% the entire time. My iTunes music pauses, and I get a "Poor Performance" pop-up in the lower right hand corner of my windows taskbar. That's how bad it is.
I'm using Android Studio 1.2.1.1
Most of the time is spent during the preDex and dex operations.
Here's what I've tried so far (separately, I haven't tried them all together):
adding gradle.properties -> "org.gradle.daemon=true"
Power Saving
Mode Invalidate Caches /
Restart Global Gradle Setings -> Offline
work Compiler -> Make project automatically
Nothing has worked yet. I can't imagine that this is a common problem, am I right? Am I being too imaptient because this really is that much slower than Eclipse?
I guess my questions are:
Could this be due to the size of my jars or so files?
I tookover a project that had many nested views in XML files. Could this be causing a problem?
I'm really reaching for straws so if anyone has any information, esepecially why the dex operation is taking up so much CPU, that would be awesome.
I guess it goes without saying that this is happening if I edit an XML file, do a rebuild, and then launch the app. If there's nothing to clean and rebuild...
when I just do a Make Project... the average build time is 3 seconds.
Here are the three improvements I was able to make:
I was preDexing my JARs every time I built the project, so I found this solution:
dexOptions {
preDexLibraries = false
}
I was using the entire Google Play Services library:
compile('com.google.android.gms:play-services:+') {
exclude module: 'support-v4'
}
When all I needed was Google Cloud Messenger:
compile('com.google.android.gms:play-services-gcm:+') {
exclude module: 'support-v4'
}
In Eclipse, I would always do a Rebuild and then launch app with the play button. In Android Studio, now I am just doing a Clean and then launch app with the play button. Also the Run button in Android Studio does NOT work every time right after the Clean. This was causing what seemed to be delays because nothing was happening. So now I leave the Gradle Console open to make sure that the run button is working, and when it doesn't I just hit it a second time.
What I used to have:
Rebuild: 26 seconds
Launch: 36 seconds
Install: 15 seconds
and now:
Clean: 8 seconds
Launch: 22 seconds
Install: 15 seconds
which is a major improvement! Hopefully this helps someone else.
As stated on the tracker page for this issue, the team has identified this as the problem:
--parallel-threads only applies to project parallelization.
For android tasks that are running in parallel, we always create as
many threads as possible
From the page, it seems that they target release 1.3 to address this (see comment #13 there).
In the meantime, what has helped me to cope on Windows 7 is to set the CPU affinity for the Android Studio process (and its child processes) to spare at least one of the cores (as suggested by comment #9 on the page).
There are many ways to do this, but you might want to try the top-voted answer on this superuser question (which suggested to use Process Lasso) that appears to work well enough for me.
In addition to optimizations specific to Gradle (see below), I recommend that you try disabling anti-virus protection for your Gradle caches directory and your Android Studio project directory. For me, this reduces my build times by roughly 50%. Excluding those same directories from Windows Search indexing can also help.
Gradle optimizations I use, in ~/.gradle/gradle.properties.
org.gradle.daemon=true
org.gradle.jvmargs=-Xmx6144m <-- Tweak this based on available RAM
org.gradle.caching=true
org.gradle.parallel=true
kotlin.incremental=true
Note that enabling caching means you sometimes have to explicitly clear your caches when switching branches. I run this script when I run into puzzling build issues.
#!/bin/bash
# Clean Android cache
./gradlew cleanBuildCache
# Clean Gradle cache, prompting for each directory
find ~/.gradle/caches -maxdepth 1 -name build-cache* -print -exec rm -rfI {} \;
# Clean Project
./gradlew clean
# Stop Gradle Daemon
./gradlew --stop
To be honest, Android Studio is hands down better than Eclipse because of the UI designer. The downside is that it uses gradle instead of Ant. Gradle is also better but slower - especially on Windows. It runs much better on Linux. If you haven't used Linux before, fear not. Linux Mint is a stable OS that has a UI that is similar to Windows. You'll be right at home in no time. It consumes fewer resources so that leaves more processing power for the gradle build. Make the switch. You'll never go back.
I'm using gradle 2.4 for a multi-project written in Java which has abount 15000 lines of code in 5 projects and i'm using Windows 7. I'm using the findbugs plugin in every sub-project.
The build itself is fast (enough) but while findbugs is running the reactivity of my PC is very bad. Most time the mouse hangs, opening websites takes a lot of time, music shutters, video hangs, etc.
If i reduce the priority of the corresponding java-process, everything is fine. For linux i found this https://askubuntu.com/questions/469709/gradle-compiling-slows-down-my-computer . I tried the suggested -PtaskThreads=x option, but that didn't help.
Is there a way to set the priority of the java-process which does the findbugs stuff to 'idle' or 'background' programmaticaly? Preferable with pure gradle options since i don't want to use some tools like CPULimit.
In an ant based java project in Netbeans, unit tests take for ever to complete. How do I spead up the unit tests. Eclipse runs the same tests quite fast and same is the case on the command-line.
Open the netbeans options window.
Go to Java -> Ant tab.
Add a new property junit.forkmode=once.
Apply and rerun the tests, you'll notice the tests run significantly faster.
For more detail about for attribute please read.
Running junit from ant beware the fork attribute
This may cause Permgen space problem. To fix that add a vm argument in the project properties dialog box.
-Xms128m -Xmx1536m -XX:MaxPermSize=512m
How significant is the improvement ?
Here are the results for a project with 11,751 unit tests.
Test run without the junit.forkmode
BUILD SUCCESSFUL
Total time: 40 minutes 17 seconds
Test run with junit.forkmode=once
BUILD SUCCESSFUL
Total time: 4 minutes 31 seconds
Not specific to ant, rather than a general suggestion:
Use SSD
Download the latest Netbeans
Remove all the plugins you don't need
Use the latest version of Java
Specifically for every project - remove unused jars (worth reviewing
your target dependency tree from time to time)
Hi most of the time i will build the Java Application using IDE option Build/Clean then Export JAR/WAR/EAR file to desktop after that will deploy in server using server admin url/console. But in some organizations will build application using ant/maven script in linux/windows. is there any difference buid using IDE and external script.
If you simply need to archive the entire project in your IDE as a WAR or EAR , then it does not really make difference if you build it through IDE or thorough ANT.
However there are certain scenarios where it requires more than just archival. For example you might want to create an EAR but do not want to include certain jars in it. Or you might want to remove all property files before creating the EAR. ANT gives you that flexibility. You can define your own build.xml and run it through ANT. It will create the EAR as defined in the build.xml.
Also it takes less time since its a automated process. So if you need to create WAR's or EAR's at a high frequency, You should probably use the scripts. They are going to save you a lot of time.
So basically automation and customization are the two main advantages of using ANTscripts
An external script like ANT can automate things for you. This may seem irrelevant when all you do is build a .JAR, but when you start to do more things it can be very helpful.
An automated build could do this for you:
Run your unit tests and create a report that you can view.
Compile your project ("Build")
Move the .JAR to a different directory.
Upload via FTP to your server.
This means that everything you currently do could be done by double-clicking an Ant script. Eclipse even has support for Ant so you can edit and run the script within your IDE.
Just an edit about the philosophy of automation. Let's say your current process takes about 15 minutes to build a .JAR and upload it to your server:
Once, 15 minutes.
Twice, 30 minutes.
Four times, 60 minutes.
You get the point. But wait, you say, writing an ANT script... that's more difficult - it might take 8 hours to learn about ANT and write a script that works.
And that is absolutely correct but the thing that makes automation grand is that now it takes 0 minutes to do your step. So, the process looks like:
Write ANT script: 480 minutes (8 hours)
Run ANT script: 0 minutes
So how do you know if you need automation? Simply think about how many times you will need to perform your manual process. If you'll only ever run it once then the comparison will be 15 minutes vs 480 minutes and you shouldn't write a script. But if you think you'll perform the process 40 times, then the comparison is 600 minutes vs 480 minutes and you would be better off writing a script.
(The above also excludes other positives about automation. For example, it's very easy to make mistakes [error in creating .JAR] when you do it manually - but the computer never makes mistakes once it's set-up correctly.)
The project currently has only 3 modules with following dependencies:
main +-> subsystem -> shared
+-> shared
After partitioning around 3.000 classes compilation takes 3 minutes instead of 30 seconds (before partitioning). I would like to split the main project into further modules.
It seems that something causes eclipse to do a full build instead of the usual incremental
build. Ant builds (in separate directories) take approx. 40 secs as before.
I already started over with freshly checked out sources.
You may want to try different build order configurations. In the Preferences dialog, find General > Workspace > Build Order. Maybe if you set your shared project to be first in the build order it might speed things up.
Good luck.
In this case ProcessMonitor http://technet.microsoft.com/de-de/sysinternals/bb896645.aspx showed that during build many resources were copied from src to bin. This was easy to fix by excluding these directories in the project settings.
I'm sorry about answering my own question.