anchor.diff:  
   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!
  +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, but you can https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/testing/TestTaskReports.html[disable this behavior]). Gradle 2.12 is 15% slower in 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
   
  
positive.code: * to compare the performance of the `master` branch with previous releases of Gradle
  * to compare various build scenarios against a single version of Gradle
  
  So typically, in the example above, we're comparing the average execution time of a build, when we run `gradle help`, for a specific scenario (an empty build with 10000 sub-projects), and compare it with previous Gradle releases. It's worth noting that this performance test suite is executed daily, allowing us to catch performance regressions very early in the development phase. Today, we have so many performance tests that running them on our infrastructure takes around 20 hours! However, this is an important price to pay: performance is a critical feature.
  
  === Writing a performance test scenario
  
  So how, in practice, do we write a performance test? It all starts with a scenario we want to test. For example, we want to make sure that we reduce the duration of test execution. The first step is then to write a build template that will let us test Gradle against this scenario. And a template has various parameters: the number of sub-projects, the number of (test) classes in source, external dependencies, ... This let us generate sample Gradle builds that are used to measure performance. Of course, those https://github.com/gradle/gradle/tree/master/subprojects/performance[performance test builds are generated with Gradle].
  
  All the graphs you will see below were generated using fully automated performance tests, and aimed at testing specific scenarios. Should you find a performance issue with Gradle, this is a great way to get started: create a new template, then send us a pull request to show the problem. Of course, all our performance tests are regular test cases, which means that we can *fail the build if we introduce a regression*. In practice, it's always a design decision to allow a regression to be shipped. One would wonder why we would release if we see a regression, but often the world is not black and white: a small regression in one area can introduce great performance improvements in another. It's typically the case when you introduce caches, which usually increase memory usage, while on the other hand dramatically reduce the execution time. After all, it's always a human process to accept a regression or not.
  
  Nevertheless, in Gradle 2.13, all you have is performance improvements! Let's focus on some of those.
  
  == Gradle vs Maven
  
  In this scenario, we are comparing the time it takes to execute `gradle clean test` vs `mvn clean test`. Of course the project is the same in both cases, and you would already notice that while I said no-one should ever be forced to call `clean`, in practice, you have to do it for Maven, so this scenario is useful to compare the time it takes to effectively build a project from nothing and execute tests. Here are the results:
  
  image::../hubpress/images/gradle-vs-maven-clean-build.png[]
  
  You can see that we were a bit slower than Maven in this case when we started to optimize things, but Gradle 2.13 is significantly faster. In particular, we came from 50s to 45s, that is to say a 10% improvement! You can notice that the graph contains some glitches: on february 2d, you can see that the time considerably increased. However, it increased in both scenarios: Maven *and* Gradle. So what you need to keep in mind when reading such graphs is that results are relative between them for a same date. This is important because:
  
  * we could change the templates between two executions of the performance build, resulting in an increase or decrease of the build time.
  * we could change hardware between two executions, leading to the same side effects
  
negative.code: = Performance is a feature
  Cédric Champeau <cedric@gradle.com>
  
  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.
  
  == The fastest thing to do is nothing
  
  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] 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’ve emphasized several categories of performance improvements:
  
  * 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
  
  Here’s an idea of the improvement you can expect:
  
  image::../hubpress/images/many-empty.png[]
  
  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
  
  