Skip to content

docs: drop benchmark numbers from the JDK caching section #1205

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
brunoborges merged 2 commits into from
Aug 5, 2026
Merged

docs: drop benchmark numbers from the JDK caching section #1205

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e4c6bd6
docs: cite reproducible JDK cache benchmark numbers
brunoborges Aug 5, 2026
6b5f505
docs: drop benchmark numbers from the JDK caching section
brunoborges Aug 5, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 4 additions & 8 deletions docs/advanced-usage.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -575,14 +575,10 @@ other than the installation it identifies. This guarantee holds without
rehashing hundreds of megabytes of JDK content on every job.

JDK caching trades cache storage and cold-run save work for faster warm setup.
In a five-run Ubuntu benchmark using Microsoft OpenJDK 17.0.19, the median warm
`setup-java` time fell from 7 seconds to 3 seconds and median warm job time fell
from 24 seconds to 18 seconds. The JDK entry added 175.3 MiB for that single
identity. Results vary by runner, distribution, JDK size, network, and cache
eviction pressure; short jobs may improve latency without changing billed
minutes. The benchmark harness and methodology, along with results from later
runs, live in
[actions/setup-java-benchmarks](https://github.com/actions/setup-java-benchmarks).
A warm run restores the installed JDK instead of downloading, verifying, and
extracting it, while the first run pays to upload it and every cached identity
consumes repository cache storage. How much time this saves depends on the
runner, distribution, JDK size, network, and cache eviction pressure.

## Platform and architecture compatibility

Expand Down