jamesfredley commented on PR #16158: URL: https://github.com/apache/grails-core/pull/16158#issuecomment-5307667227
## CI measurement (first draft run) All 59 jobs passed. Comparing the `Build Grails-Core` matrix jobs against the median of the three most recent successful `gradle.yml` runs on `8.0.x` (runs `31893711990`, `31892777441`, `31730582241`): | Job | Baseline median | This PR | Change | |---|---:|---:|---:| | Ubuntu JDK 21 | 84.8 min | 59.5 min | **-29.8%** | | macOS JDK 21 | 77.9 min | 62.5 min | **-19.8%** | | Windows JDK 25 shard 2 | 45.4 min | 36.6 min | **-19.4%** | | Ubuntu JDK 25 | 81.0 min | 77.4 min | -4.4% | | Windows JDK 25 shard 1 | 43.1 min | 43.5 min | +0.9% | | Windows JDK 25 shard 0 | 77.1 min | 95.4 min | **+23.7%** | Whole-workflow wall clock was 95.5 min against a ~2h14m median. ### How much to trust this Not much yet, on its own. This is **one** run against a three-run baseline, and per-job variance on GitHub runners is large: baseline `Windows JDK 25 shard 0` alone ranged **66.8 - 93.7 min** across those three runs, so this PR's 95.4 min is only just outside its own baseline spread. Treat the Windows shard 0 regression and the Ubuntu JDK 21 improvement with equal caution until there are more samples. What makes the direction plausible rather than noise is that the local A/B benchmark was run in **both** orderings on an idle machine, and the improvement held each way (19.5% with baseline first, 22.2% with this branch first). ### What is actually being measured here **CI fork counts are unchanged by this PR** - the `isCiBuild` budgets stay at 4 (root) and 3 (`grails-gradle`). So any CI movement comes solely from the per-fork `-XX:ActiveProcessorCount` cap, not from running fewer forks. On a 4-vCPU runner each fork now sizes its GC and JIT pools for 2 processors instead of 4, which is a much smaller change than the local one (20 processors down to 2). The macOS result is the most interesting one for day-to-day work, since most committers develop on macOS and GitHub's macOS runners are the smallest at 3 vCPU / 7 GB. ### Suggested next step Re-run this workflow a couple more times before drawing conclusions, so each job has a comparable sample count to the baseline. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
