We used to use Ant as a build tool which is based on XML language which is verbose language and Ant is pretty slow compare to latest build tools also .After Ant we moved to Maven, which is widely used Java code build tool in industry. Still maven have certain limitation, which is overcome by Gradle.
Build performance is critical to your productivity. The longer the build takes to complete, the more likely you’ll be taken out of your development flow. On top of that, since you run the build many times a day, even small periods of waiting can add up to significant disruption. The same is true for builds run on CI: the faster they are, the faster you can react to new issues and the more capacity you will have to do innovative experiments.
All this means that it’s worth investing some time and effort into making your build as fast as possible.
Gradle do the checksum match and build change only classes which save lot of time of developers. Developer can deliver code in with high velocity, instant feedback loop process is created.
Tuning is required to optimise the build process.
Get the existing profiling of the gradle build by using command :
$ gradle --profile clean buildAdjust the daemon’s heap size
By default Gradle will reserve 512m of heap space for your build, which is plenty for most projects, especially if you follow our advice on forked compilation further down in this section. However, some very large builds might need more memory to hold Gradle’s model and caches. If this is the case for you, you can check in this larger memory requirement in your gradle.properties file:
org.gradle.jvmargs=-Xmx2048Mreference : Build Environment
Most builds consist of more than one project and some of those projects are usually independent of one another. Yet Gradle will only run one task at a time by default, regardless of the project structure (this will be improved soon). By using the --parallel switch, you can force Gradle to execute tasks in parallel as long as those tasks are in different projects.
You could see big improvements in build times as soon as you enable parallel builds. The extent of those improvements depends on your project structure and how many dependencies you have between them. A build whose execution time is dominated by a single project won’t benefit much at all, for example. Or one that has lots of inter-project dependencies resulting in few tasks that can be executed in parallel. But most multi-project builds should see a worthwhile boost to build times.
Parallel builds require projects to be decoupled at execution time, i.e. tasks in different projects must not modify shared state.
You can also make building in parallel the default for a project by adding the following setting to the project’s gradle.properties file:
gradle.properties
org.gradle.parallel=trueCompiler daemon
The Gradle Java plugin allows you to run the compiler as a separate process by using the following configuration for any JavaCompile task:
build.gradle
<task>.options.fork = trueor, more commonly, to apply the configuration to all Java compilation tasks:
tasks.withType(JavaCompile).configureEach {
options.fork = true
}Forking options
Gradle will run all tests in a single forked VM by default. This can be problematic if there are a lot of tests or some very memory-hungry ones. One option is to run the tests with a big heap, but you will still be limited by system memory and might encounter heavy garbage collection that slows the tests down.
Another option is to fork a new test VM after a certain number of tests have run. You can do this with the forkEvery setting:
tasks.withType(Test).configureEach {
forkEvery = 100
}
