anchor.diff:  
   === 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...
  +Sometimes, improving performance is a matter of serendipity. We recently discovered that some performance tests were executing significantly faster on our CI server than locally, but were unsure of the cause. 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.
   
  -== Improving the Tooling API
  +== Faster IDE integration
   
  -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.
  +The Tooling API typically allows IDE vendors to integrate Gradle. This is typically what we do with http://projects.eclipse.org/projects/tools.buildship[Buildship] It has very specific needs and in particular, it has to be both backwards and forward compatible, meaning a certain version of the TAPI can execute Gradle builds for both older and newer versions of Gradle. Of course, a developer would only benefit from the latest improvements by using both the latest 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:
   
  
positive.code: 
  image::../hubpress/images/gradle-vs-maven-cleanTest-test.png[]
  
  This scenario is "unfair" to Gradle, and meant to compare what happens when we just want to re-execute the tests. As you may know, when running `mvn test`, Maven will re-execute the tests even if nothing changed. Gradle does nothing in that case, because everything is "up-to-date". So to emulate the behavior of Maven, we need to clean-up the test results so that we re-execute the tests and re-generate the reports. As you can see, in this scenario, Gradle was significantly slower than Maven. Now, it is faster, while doing also more work: Gradle not only runs the tests, but also generates 3 types of reports: a binary one, an XML one (for CI integration) and eventually an HTML report (for use by us, poor humans). Gradle 2.12 is 15% on this scenario, and a large amount of improvement has been done by optimizing the classpath of the forked JVMs used for tests. In 2.12, almost the whole Gradle classpath was used on forked VMs, when in reality we just need a subset of Gradle classes (basically to communicate between the forked VM and the daemon). By optimizing this classpath, we can now reduce classpath scanning and significantly improve the time it takes to execute tests. If you ever noticed a "pause" when Gradle was about to execute tests, it has now gone!
  
  === Reports are generated in parallel
  
  
negative.code: 
  So how did we manage to improve this? First of all, once a scenario is written and performance tests running, we need to profile the builds. For that purpose, we're using different tools, from https://www.yourkit.com/[YourKit Java Profiler] to http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html[Java Mission Control], the JIT logs or simply good old `System.out.println` statements. In the end, we try to identify what is causing slowdown and write a document summarizing our findings. Those documents are all public, and you can find them in our https://github.com/gradle/gradle/tree/master/design-docs/features/faster-builds[GitHub repository]. Once we've identified hotspots and written down the profiling results, we extract stories for improvement and actually go to the implementation phase. This "profiling to stories" phase is very important, because while a profiler will be very helpful in identifying hotspots, it will be no help when it comes to interpreting the results: often, rewriting an algorithm can be much more efficient than trying to optimize a SAX parser...
  
  === Optimizing the communication between the daemon and the client
  
  As we explained, we're primarily (but not only) focusing on improving performance when the daemon is activated. One issue with the daemon is that you have a forked JVM. When you run `gradle`, the client process, the one from the command-line, starts communicating with a long-living process, the daemon, which is effectively executing the build. And typically, to see the logs as the build is running, you need to forward events from the daemon to the client. Before 2.13, this communication was synchronous. This means that the log messages were sent synchronously between the daemon and the client. This was inefficient, because we were blocking on network I/O where we could actually perform some build operations. In 2.13, not only is communication asynchronous, but we also optimized the protocol that is used to communicate between the client and the daemon and how the client responds to these events.
  
  === Forked processes start up faster
  
  