Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Refactored buildSrc into modules to improve feedback cycles

- Created module boundaries around different languages and slow tests

    • -313
    • +0
    • -124
    • +0
    • -21
    • +0
    • -130
    • +0
    • -80
    • +0
    • -44
    • +0
    • -305
    • +0
    • -48
    • +0
  1. … 517 more files in changeset.
Make sure ProjectGeneratorTask is used appropriately

- Add a description for mediumSwiftMulti

- Add a TODO for getting rid of CppMultiProjectGeneratorTask

  1. … 2 more files in changeset.
Rename ProjectGeneratorTask -> TemplateProjectGeneratorTask

This provides a common base task for most of the project generators

    • -1
    • +1
    • -0
    • +48
Add Swift performance tests

- Add project generator that can use build-builder

- Add a mediumSwiftMulti performance project

- Add a task to checkout build-builder

- Add a task to install build-builder

    • -0
    • +108
  1. … 3 more files in changeset.
Javadoc on the RemoteProject task

In order to clarify branch & ref properties purposes.

Signed-off-by: Paul Merlin <>

Enhance the RemoteProject task to support git ref checkout

Signed-off-by: Paul Merlin <>

Explain how @Internal annotated inputs are tracked

Fix buildSrc/AbstractProjectGeneratorTask task properties

    • -31
    • +81
  1. … 1 more file in changeset.
Always generate `settings.gradle`

If not, when running a build in the performance project, Gradle may

search upwards to find the settings.gradle of the Gradle build itself

and start building buildSrc.

Add performance templates for native tests

    • -0
    • +53
Add performance test for using macro includes

  1. … 3 more files in changeset.
Finish native performance tests

Fixes gradle/gradle-native#158

    • -0
    • +66
  1. … 12 more files in changeset.
Add {small|medium|big}CppLibrary performance tests

This takes care of single-project C++ builds of three varying sizes.

Part of gradle/gradle-native#158

    • -0
    • +30
  1. … 4 more files in changeset.
Revert "Use separate source directories for native performance tests"

This reverts commit 94110a268552560f08804eafb395d125939b131f.

    • -2
    • +3
  1. … 1 more file in changeset.
Use separate source directories for native performance tests

I also removed the unused files from the source directories.

Our file system mirror will not be used if we use includes in directory

trees, which makes the tests much slower.

    • -3
    • +2
  1. … 1 more file in changeset.
Fix task dependencies between test project generation performance tests

    • -0
    • +21
  1. … 2 more files in changeset.
Fix performance test templates

Instantiate performance test projects at execution time

The detailed configuration possibilities are now unused and

instantiating these objects at configuration time just adds

unnecessary overhead.

    • -16
    • +10
Cleanup Java performance test projects and scenarios

- Sort tests into packages

- Add new test projects: `largeMonolithicJavaProject`,

`largeJavaMultiProject`, `mediumJavaMultiProjectWithTestNG`

- Cleanup template.gradle file

-- Remove "old Java" templates

-- Remove unused Scala and Groovy performance

test project configurations

-- Remove large enterprise performance test projects

- Simplify Java scenarios: clean assemble, first use, change test,

getting IDE models, dependency report, abi change, non-abi change

- Adjust tests to not use old test projects anymore

- Add file mutators

  1. … 96 more files in changeset.
Add a performance scenario to measure the performance of exclude rule merging

  1. … 2 more files in changeset.
Fix RemoteProject setup

Run GSK performance tests against small project only

Until we're sure v0.5.0 is used for all scenarios.

See gradle/gradle-script-kotlin#184

    • -4
    • +15
  1. … 6 more files in changeset.
Introduce GradleScriptKotlinBuildPerformanceTest

With first use scenario against many projects.

See gradle/gradle-script-kotlin#184

    • -0
    • +28
  1. … 5 more files in changeset.
Simplify performance measurements

The many measurements that we injected into the build under test were

skewing our measurements to the point of making them unreliable or

unrealistic. We now only measure end to end build time. Here's a breakdown

with the rationale for removing each other measurement:

- configuration time: can be done by having a `gradle help` scenario instead

- execution time: the user does not care whether a long build is stuck in execution or configuration

- setup/teardown: was ill-defined anyway, basically total - configuration - execution

- JIT compile time: this is nothing we can influence and thus pointless to measure

- Memory usage: Was only measured at one point in the build, which doesn't tell us anything about

any problems at any other point in the build

- GC CPU time: If this increases we'd see it in total execution time

Generally, looking at the graphs has never pointed us directly at the problem, we always need to

profile anyway. So instead of skewing our measurements with lots of profling code, we should

instead use a dedicated profiling job to measure if we actually see a regression.

Memory usage can be tested indirectly by giving each scenario a reasonable amount of memory.

If memory usage rises above that reasonable limit, we'd see execution time rise, telling us about

the regression. Generally, we do not optimize for smallest memory usage, but for fastest execution

with reasonable memory overhead.

This change also removes all JVM tweaking and wait periods which we introduced in an attempt to

make tests more predictable and stable. These tweaks have not really helped us achieve more stable

tests and have often done the opposite. They also add lots of complexity and make our tests more

unrealistic. A real users will not add all these JVM options to Gradle.

    • -27
    • +0
  1. … 57 more files in changeset.
Fix native performance tests

    • -1
    • +3
Fix generation of "java software model" templates

  1. … 8 more files in changeset.
Use `buildSrc` instead of embedding classes in each subproject

The test projects all used their own copy of `CheckstyleExtension` and a custom plugin. This doesn't

reflect real projects at all. Instead, this commit changes the project layout to add a `buildSrc`

directory which contains those custom tasks/plugins.

  1. … 6 more files in changeset.
Integrate `largeEnterpriseBuild` into our performance test suite

  1. … 2 more files in changeset.
Add a deeper dependency structure for native dependents

+review REVIEW-6181

    • -2
    • +24
  1. … 2 more files in changeset.
Fix measurement plugin jar not being generated for Android performance tests

    • -0
    • +59
  1. … 2 more files in changeset.