JavaIDEModelPerformanceTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Rebaseline JavaIDEModelPerformanceTest

JavaIDEModelPerformanceTest has been regressed gradually for a long

time, rebaseline it.

Refine performance baseline selection logic (#10972)

Refine performance baseline selection logic

See https://github.com/gradle/gradle-private/issues/2571

  1. … 25 more files in changeset.
Refine performance baseline selection logic (#10972)

Refine performance baseline selection logic

See https://github.com/gradle/gradle-private/issues/2571

  1. … 25 more files in changeset.
Refine performance baseline selection logic

See https://github.com/gradle/gradle-private/issues/2571

  1. … 25 more files in changeset.
Fix version string

Rebaseline JavaIDEModelPerformanceTest

Both `get IDE model on largeJavaMultiProject for {IDEA,Eclipse}` seem

to have regressed by about 2-3%.

See gradle/gradle-private#2584

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.
Rebaseline some scenarios

We saw gradual regression in some of the scenarios. Rebaseling them.

  1. … 3 more files in changeset.
Rebaseline some scenarios

We saw gradual regression in some of the scenarios. Rebaseling them.

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

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

  1. … 35 more files in changeset.
Rebaseline get IDE model on largeJavaMultiProject for IDEA

Looking at the history, there's a regression since long time ago

so it might be a little to track. Rebaseline it.

Rebaseline JavaIDEModelPerformanceTest.get IDE model on largeJavaMultiProject for IDEA

Looking at the history, there's a gradual regression over time. Rebaseline it for now.

Lock-in some performance improvements

  1. … 31 more files in changeset.
Rebaseline JavaIDEModelPerformanceTest

There has been a small regression which we accept, similar to the

same regression in the IDEA test.

Rebaseline performance test to unblock master

Fixing the regression is tracked as gradle/build-cache#1473

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 'get IDE model on largeJavaMultiProject for IDEA'

Rebaseline performance tests after merging single project lock changes

  1. … 31 more files in changeset.
Rebaseline improved scenario

  1. … 3 more files in changeset.
Fix imports

Fix unused imports in performance tests

  1. … 1 more file in changeset.
Rebaseline performance tests

Those tests correspond to accepted performance regressions

related to enabling improved POM support by default.

  1. … 2 more files in changeset.
Rebaseline `get IDE model on <> for {IDEA,Eclipse`

Those two are slower probably due to the container changes.

@melix didn't see any improvements which can be done for those cases.

Issue: https://github.com/gradle/gradle-private/issues/1510

Issue: https://github.com/gradle/gradle-private/issues/1511

Temporarily disable `get IDE model` performance tests

So that we can get a nightly, to accept the performance regression.

  1. … 2 more files in changeset.
Rebase Tooling API performance test

There was a small (5ms) regression in one scenario,

related to logging TAPI events in the background.

This appears to be a static overhead, not increasing

with the size of the project, so it is acceptable

given the correctness implications of that change.