Julia Performance Tracking
Dashboard for Julia language performance: daily Nanosoldier benchmark reports,
CI build/test timing, TTFX, distribution size,
sysimage build time, PkgEval and package-server downloads. The Overview tab sums up every source, the Commit tab gathers
everything recorded for one commit or PR (/commit?c=<sha or PR number>), and the other tabs go deep.
Live: https://perf.julialang.org/
Short paths open a tab directly and forward any other query parameters:
/overview,
/commit,
/diff, /history,
/timing,
/workers, /ttfx,
/sizes, /build-stages,
/downloads, /pkgeval,
/activity.
Each is a small redirect page under a directory of that name; the ?tab= URLs
they resolve to keep working as before.
How it works
One EC2 host (infra/terraform/, see its README) runs everything from one
container image (Dockerfile):
- Nine fetchers write a SQLite database every half hour, and the CI timing,
agent and GitHub ones every 10 minutes (
db/schema.sql):
fetch_timing.jl: Buildkite job timings (julia-ci, plus the legacy
julia-master and julia-master-scheduled pipelines, which stopped
receiving builds in July 2026)fetch_benchmarks.jl: Nanosoldier benchmark history, every estimate of
every benchmark and Nanosoldier's own verdictsfetch_pkgeval.jl: PkgEval reports, with every package's outcomefetch_ttfx.jl: TTFX results (package precompile, load and run times of the
Julia-TTFX-Snippets tasks,
the load and run times also from repeats with the GC disabled, the
invalidations of each task script, and from the job's trace logs the methods
compiled again after an invalidation)
from the TTFX job on every julia-ci master build, and from the weekly
TTFX release job that measures the newest stable release as a reference, see
julia-buildkite/utilities/ttfxfetch_sizes.jl: the size of the binary distribution (tools/measure_sizes.jl)
of every julia-ci master build, from the tarball in the nightlies bucket, and of
the latest julia-pr build of every open pull request, from its build job's
artifact (the token needs read_artifacts). db/import_sizes.jl imported the
history before that from manyjulias buildsfetch_sysimage.jl: how long the build job of every julia-ci master build
spends making the system image, stage by stage (compiling the compiler, Base, the
stdlibs, the precompile statements, emitting each image), parsed from the job's
log; the jobs come from fetch_timing.jl's rows and the logs need no tokenfetch_packages.jl: package-server download rollups, per package too,
with names from the General registryfetch_agents.jl: a snapshot of the connected Buildkite agents on every
run, and the queue and run times of every julia-pr and julia-ci job for the
queue backlog (the token needs the read_agents and read_builds scopes)fetch_github.jl: every issue, pull request and master commit of
JuliaLang/julia, for the Activity tab. The first run imports the history from
the assets of the release and catches up from there, so no token
is needed
To use the data yourself, docs/querying.md covers the API
(/api/ lists its routes), SQL, the snapshot and the extracts, with example queries;
/llms.txt is the short version for agents.
Pushing to main builds the image and deploys it (.github/workflows/deploy.yml);
health.yml checks the host once a day. The plan and its history:
docs/database-migration.md.
To run the site locally, download the snapshot and serve it:
curl -O https://perf.julialang.org/data/ci-timing.sqlite.gz && gunzip ci-timing.sqlite.gz
julia --project db/serve.jl --db ci-timing.sqlite --site .
Related
The "Benchmarks" tab embeds julia-perf,
a fork of rust-lang/rustc-perf
adapted for Julia. Thanks to the Rust team for their work on that project.
Analytics
The site counts visits with Google Analytics, one page view per tab shown
(/overview, /timing, ...). Filters and selections, which live in the query
string, are never sent. Nothing is loaded when the browser sends Do Not Track
or Global Privacy Control, or on a local checkout.
License
MIT, see LICENSE.
