Repository navigation
Halve random-access benchmark CI time: 5 s measurements, parallel and cached data generation - #11244
Merged
Merged
Conversation
…e legacy taxi runs Each of the 80 per-combination invocations measured for 10 s, and every taxi invocation repeated the legacy fixed-index taxi measurement, which the merge then discarded. Measure for 5 s and run the legacy taxi measurement only with the correlated pattern, which covers both open modes once. Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UeniB9mYWJs2z49XPgvbPi Signed-off-by: Claude <noreply@anthropic.com>
Revert the benchmark run changes from the previous commit, so measurements keep the 10 s time limit and the legacy taxi runs. Data generation now runs one process per dataset concurrently. LitData, about 80% of generation time and independent of Vortex, is generated in a separate stage and cached with actions/cache, keyed on the Parquet files it is converted from plus the conversion script and litdata version. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UeniB9mYWJs2z49XPgvbPi Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
Only Vortex, Arrow IPC and Lance are written on every run. Parquet and LitData are restored from actions/cache, keyed on the dataset generators, the parquet/arrow/rand crate versions in Cargo.lock, and the LitData conversion script and version. Local and S3 jobs use separate keys. This replaces the separate LitData generation stage: every format is now generated in one parallel pass that skips files restored from the cache. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UeniB9mYWJs2z49XPgvbPi Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
Experiment: halve the per-measurement time limit from 10 s to 5 s to check whether the benchmark results change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UeniB9mYWJs2z49XPgvbPi Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
Contributor
Polar Signals Profiling ResultsLatest Run
Previous Runs (1)
Powered by Polar Signals Cloud |
Contributor
Benchmarks: Random Access 📖Commits: PR How to read Verdict and Engines
vortex / arrow-ipc / ns (1.046x ➖, 1↑ 7↓)
random-access / vortex-file-compressed / ns (1.000x ➖, 0↑ 0↓)
random-access / parquet / ns (1.009x ➖, 0↑ 0↓)
random-access / lance / ns (1.005x ➖, 0↑ 0↓)
random-access / litdata / ns (1.000x ➖, 0↑ 0↓)
|
Temporarily undo the 5 s experiment so the PR benchmark measures this branch at 10 s, to separate run-to-run noise from the effect of the time limit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UeniB9mYWJs2z49XPgvbPi Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
A 10 s control run on this branch moved by the same amount against develop as the 5 s run, so halving the time limit does not change the results; it only halves the benchmark step. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UeniB9mYWJs2z49XPgvbPi Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
joseph-isaacs
marked this pull request as ready for review
November 4, 2026 22:15
Contributor
Author
|
CI failures on this PR so far, none caused by its diff, which only touches the random-access benchmark script and two benchmark workflows:
Generated by Claude Code |
robert3005
approved these changes
Nov 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The local random-access benchmark job took ~23 min: 18.3 min of timed measurements and 4.1 min of data generation, ~80% of which was writing LitData. This PR cuts the job to roughly 12 min without changing what is measured.
Changes
scripts/random-access-split.pypasses--time-limit 5. Each number is a median per-lookup latency, so the time limit only sets the sample count. Even at 5 s the fast formats take thousands of samples.--prepare-dataruns one process per dataset concurrently. Each dataset's output is printed in its own log group.develop-bench.ymlandpr-bench-runner.ymlrestore Parquet and LitData withactions/cache. Vortex, Arrow IPC and Lance are written every run, so the formats under test always come from the current code and lockfile. The key covers the dataset generators (vortex-bench/src/datasets/**,vortex-bench/src/random_access/**), theparquet/arrow-*/rand*versions inCargo.lock, the LitData script,litdata.rsand the pinned litdata version. Local and S3 jobs use separate keys.Results on this PR
All three runs use the same code; only the time limit or cache state differs.
With 5 s and a cache hit the job should take ~11.5 min.
Do the numbers change? No. Hot geomeans vs develop:
Both runs report "No clear signal". Arrow IPC nested-lists/nested-structs read ~10–20% slower than develop at both 5 s and 10 s, so that shift is not caused by the time limit. It is either run-to-run variance between bench machines or something about PR runs; worth a separate look if it persists.
Checks:
yamllint --stricton both workflows andgit diff --check. The workflow changes were exercised by the benchmark runs above, covering both a cache miss and a cache hit.🤖 Generated with Claude Code
https://claude.ai/code/session_01UeniB9mYWJs2z49XPgvbPi