RichConsolePerformanceTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Rebaeline all performance tests

Most scenarios haven't been rebaselined since 4 month ago, which makes them

fragile because of the gradual performance regression. Rebaseline all of them.

  1. … 25 more files in changeset.
Rebase RichConsolePerformanceTest

Same as 79e87751

Rebase to latest 6.0 nightly

#10348 has an influence on some of these performance scenarios.

(correcting 90e852d and 85933bb)

  1. … 29 more files in changeset.
Rebase performance tests with 5.7-20190722220035+0000 baseline

#10348 might have an influence on the performance of these scenarios.

  1. … 25 more files in changeset.
Remove newlines added by IDEA

  1. … 14 more files in changeset.
Convert some easy classes to use Gradle profiler

  1. … 18 more files in changeset.
Convert some easy classes to use Gradle profiler

  1. … 19 more files in changeset.
Convert some easy classes to use Gradle profiler

  1. … 19 more files in changeset.
Convert some easy classes to use Gradle profiler

  1. … 19 more files in changeset.
Rename performance test infrastructure legacy classes

To make clear that they are using the Gradle build internal

infrastructure.

  1. … 44 more files in changeset.
Rebaseline all performance test scenarios

There seems to be tiny gradual regression in performance, which causes unbearable

flakiness. Rebaselining all scenarios to catch future regressions.

  1. … 30 more files in changeset.
Try latest nightly

  1. … 35 more files in changeset.
Try latest nightly

  1. … 35 more files in changeset.
Lock-in some performance improvements

  1. … 31 more files in changeset.
Rebaseline performance tests

  1. … 30 more files in changeset.
Rebaseline to the same commit to the distribution commit

  1. … 31 more files in changeset.
Rebaseline performance tests

To account for minor regression due to detailed container

callback instrumentation. This information will help find

performance issues that are much bigger than the small overhead

the instrumentation adds.

  1. … 31 more files in changeset.
Lock in recent performance improvements

  1. … 31 more files in changeset.
Rebaseline performance tests

We introduced a ThreadLocal in the project locking which slowed things

down a little bit (10s of ms) in several builds. Rebaselining to prevent

this from affecting all branches.

  1. … 31 more files in changeset.
Rebaseline performance tests after merging single project lock changes

  1. … 31 more files in changeset.
Rebaseline performance tests

The introduction of the "platform" support introduced a couple small regressions,

but also improvements in some cases. This commit re-enables the Java IDE performance

test now that we have a baseline to compare with. Work on improving performance

is going to happen later.

  1. … 31 more files in changeset.
Rebaseline all performance tests

To lock in memory usage improvements.

  1. … 32 more files in changeset.
Lock in some dependency management performance improvements

  1. … 31 more files in changeset.
Rebaseline performance tests

There is a known performance regression due to more work done during dependency resolution. Future

commits will attempt to mitigate the regression.

  1. … 31 more files in changeset.
Rebaseline performance tests

To account for a regression across most tests,

which was caused by a bugfix for lazy task creation.

Lazy task creation was only that fast because of

that bug, so this new performance level is the

expected one. We can definitely improve it further,

see https://github.com/gradle/gradle-native/issues/678

  1. … 30 more files in changeset.
Rebaseline performance tests

This change accepts a 1% regression in the

ProjectCreationPerformanceTest."create many empty projects" test.

The original baseline contains a bug that accidentaly made the

execution faster.

  1. … 31 more files in changeset.
  1. … 31 more files in changeset.
Rebaseline performance tests

  1. … 29 more files in changeset.
Rebaseline performance tests

To account for recent configuration time improvements.

  1. … 29 more files in changeset.
Lock in some performance improvements

There have been several performance improvements both in dependency management and thanks

to software model bridging.

  1. … 29 more files in changeset.