anchor.diff:  = Performance is a feature
   Cédric Champeau <cedric@gradle.com>
   
  -At Gradle Inc., we take performance seriously. Every Gradle release comes with performance improvements, but starting from Gradle 2.13, we decided to start working on a _performance burst_ to tackle long standing issues that affect most of our users. In this blog post series, we will explore how we approach performance issues, and what improvements you can expect in the 2.13 release and the upcoming ones.
  +At Gradle Inc., we take performance seriously. While we bundle performance improvements into every Gradle release, we’ve kicked off a concerted effort called a _performance burst_ from Gradle 2.13 in order to make building software faster and more enjoyable for all of our users. In this blog post, we will explore how we approach performance issues, as well as what improvements to expect in the 2.13 release and beyond.
   
  -== You're never as fast as when you have nothing to do
  +== The fastest thing to do is nothing
   
  -First of all, the biggest performance improvement is when you have nothing to do. That's why, unlike traditional build tools such as Maven or Ant, Gradle focuses on incremental builds. Why would you ever run `clean` when you don't need to? For some developers, running `clean` became a conditioned response to a broken build tool. Gradle doesn't have such an issue: being aware of all inputs and outputs of a task, it is reliably capable of handling incremental builds. That's why we usually focus on making incremental builds faster, and recommand to turn the daemon on.
  +Building software takes time, which is why the biggest performance improvement is cutting steps out of it entirely. That's why, unlike traditional build tools such as Maven or Ant, Gradle focuses on incremental builds. Why would you ever run `clean` when you don't need to? For some developers, running `clean` became a conditioned response to a broken build tool. Gradle doesn't have such an issue: aware of all inputs and outputs of a task, it is reliably capable of handling incremental builds. Most builds will be incremental, and that's why we focus so heavily on optimizing this case. One way that we accomplish this is through the Gradle daemon.
   
  -The https://docs.gradle.org/current/userguide/gradle_daemon.html[Gradle daemon] is your best friend when it comes to achieving the best performance with Gradle. Basically, the daemon is a hot JVM hosting the Gradle runtime, making it possible to run subsequent builds much faster: instead of spawning a new JVM for each build, we can benefit from all the goodness of having a cached JVM, in particular, benefit from the JIT (just in time compiler). While turning on the daemon has a cost for the first build, the amount of time that you will gain for each subsequent build is very important. In Gradle 2.13, we focused our improvements when the daemon is activated, and we're preparing Gradle to enable this by default in Gradle 3.0. However, the performance improvements we implemented will benefit all users, independently of whether they use the daemon or not.
  +The https://docs.gradle.org/current/userguide/gradle_daemon.html[Gradle daemon] can dramatically improve your build performance by allowing build data to persist in memory between build invocations and avoiding JVM startup times on each build. The daemon is a hot JVM hosting the Gradle runtime, making it possible to run subsequent builds much faster: instead of spawning a new JVM for each build, we can benefit from all the goodness of having a cached JVM - in particular, we realize a strong benefit from JIT (just in time compilation). While turning on the daemon has a cost for the first build, the amount of time that you will gain for each subsequent build more than offsets the initial cost. In Gradle 2.13, we focused our improvements when the daemon is activated, and we're preparing to enable this by default in Gradle 3.0. Other performance improvements we've implemented will benefit all users, independently of whether they use the daemon or not (and if you don't use the daemon yet, we strongly encourage you to try it out!).
   
  -As you can read in our https://docs.gradle.org/2.13-rc-1/release-notes[release notes], we have worked on different topics:
  +As you can read in our https://docs.gradle.org/2.13-rc-1/release-notes[release notes], we’ve emphasized several categories of performance improvements:
   
  -* reducing the build configuration time, that is to say, reduce the fixed cost of creating and configuring a Gradle build
  -* reducing the test execution time, that is to say reducing the overhead of Gradle compared to just executing tests in an IDE, typically
  -* improving the performance of the Tooling API
  -* improving the communication of Gradle with the daemon process
  +* reducing the build configuration time, that is to say, reducing the fixed cost of creating and configuring a Gradle build
  +* reducing the test execution time; i.e., reducing the overhead of Gradle compared to just executing tests in an IDE
  +* improving the performance of importing a project in an IDE
  +* reducing communication latency between the interactive Gradle client and the daemon process
   
   == Reducing configuration time
   
  -To give you an idea of what kind of improvements you can expect, it's good to start with a graph that illustrates the improvement:
  +Here’s an idea of the improvement you can expect:
   
   image::../hubpress/images/many-empty.png[]
   
  -
  -In this case, we're measuring the time it takes to run `gradle help` for a project that contains a lot of subprojects (10000 projects). You can see that when we started optimizing configuration time, the `master` branch was slower than Gradle 2.7. Now, Gradle 2.13 is faster than ever! However, more than the improvement, it's _how_ we get to this that is important. Improving performance is a process, and here is how it works.
  +So the example above yields a typical performance test metric: we’re comparing the average execution time of a build when we run `gradle help` for a project that contains a lot of subprojects (10000 projects). You can see that when we started optimizing configuration time, the `master` branch was slower than Gradle 2.7. Now, Gradle 2.13 is faster than ever! We have measured up to 25% reduction on our own builds! However, more than the improvement, it's _how_ we get to this that is important. Improving performance is a process, and here is how it works.
   
   === Performance test suite
   
  
positive.code: 
  === Bugfixes
  
  Sometimes, improving performance is also being lucky. Typically, we discovered that for some reason, some performance tests were executing significantly faster on our CI server than locally. After doing some profiling, we realized that the code to propagate properties from the various `gradle.properties` files to the actual `Project` was very inefficient: the more properties you had in your various `gradle.properties` file, the longer it would take to start the build! We identified the problem and fixed this. If you ever had a build that was unexpectedly slower on your computer than on your mate's one, maybe this was your problem...
  
  == Improving the Tooling API
  
  The Tooling API typically allows IDE vendors to integrate Gradle. The Tooling API has very specific needs. In particular, it has to be both backwards and forward compatible. What does it mean? It means that a certain version of the TAPI can execute Gradle builds for older version of Gradle as well as newer versions of Gradle. Of course, a developer would only benefit from the latest improvements by using both the highest version of the Tooling API and Gradle, but it leads to interesting architecture.
  
  In this case, the Tooling API heavily relies on reflection to invoke methods. In Gradle 2.13, we significantly improved caching, which led to spectacular results:
  
  
negative.code: == Improving build startup time
  === Faster script compilation
  
  When executing Gradle builds for the first time, you can see, as part of the "configuration" phase, that Gradle is actually compiling the build scripts. Despite being scripts, Gradle build files are written in Groovy and are nevertheless compiled to bytecode. This is time consuming, but has been optimized by the Gradle team. In particular, Gradle has to compile the scripts several times, with different classpaths, in order to compile scripts that contain references to remote resources such as plugins.
  
  In Gradle 2.13, we changed the way Gradle scripts are compiled, and optimized two scenarios:
  
  