anchor.diff:  
   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...
   
  -So here is some of the things we improved in 2.13.
  -
   === 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 communication is asynchronous, but we also optimized the protocol that is used to communicate between the client and the daemon, as well as optimized how the client renders those log events.
  +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
   
  
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: == 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:
  
  