Rust vs C FFI Relative Dashboard
Default view tracks Rust/FFI relative deltas by target and scenario. Parity band is loading from payload.
Level Profile (compress + decompress + ratio)
Plain Rust vs FFI compression speed, decompression speed, and output
ratio plotted against compression level on the X-axis (speeds on the
left axis; ratio on the right axis, compressed/input,
lower=better). The four *-dict toggles add
trained-dictionary compress and decompress speed series on the same
level axis for scenarios measured with a dictionary. Controlled by the
Target, Scenario, and
Level selectors at the top of the page (default
all = cumulative arithmetic mean across that dimension).
The Snapshot dropdown either pins every line to
one generated_at run, or — on the default
latest setting — picks each (level, metric) point from
the most recent snapshot of its own cohort independently, so points
can come from different snapshots across the X-axis. Decompress rows
are additionally averaged across both source variants
(rust_stream + c_stream) per side, giving
one deterministic data point per (level, side) regardless of bench
iteration order.
Aggregate over all levels (commit timeline)
Same six series as Level Profile, but plotted against
snapshot / commit time on the X-axis and
averaged across every (level, scenario,
target) cohort for that snapshot — each row's logical metric
(compress speed / decompress speed / ratio) is bucketed
separately, and within each decompress_speed
cohort the two source variants (rust_stream +
c_stream) collapse into the inner mean so a
(level, scenario, target) with two sources contributes the
same weight to the snapshot average as a (level, scenario,
target) with one. Each point answers
“across the whole bench matrix, where are we right now vs
FFI?” — useful for spotting aggregate dynamics across commits
regardless of which level or corpus drove the change. The top
Target / Scenario / Level filters still apply: setting any of
them to a specific value narrows the average to that slice.
WebAssembly: structured-zstd vs @bokuweb/zstd-wasm
Tracks our two wasm payloads (simd128 +
scalar) against the most popular npm wasm zstd,
@bokuweb/zstd-wasm (an emscripten build of the C
reference), over time. Source: node
zstd-wasm/bench/bench.mjs, run as a push-to-main shard
(bench-wasm in ci.yml). Pick a
Metric (compress speed, decompress speed, or
output ratio), a payload Kind (plain or
dictionary), a Scenario and a
Level; each line is one engine plotted across
snapshots. For the speed metrics the secondary axis also shows
our throughput as a multiple of bokuweb (>1 =
faster); for the ratio metric lower is better
(compressed/input).
Raw timings (secondary view)
Canonical raw series are still available from data.js via github-action-benchmark.
| Series | Latest commit | Bench count |
|---|
Reports: benchmark-report.md, benchmark-delta.md, benchmark-delta.json, benchmark-relative.json