perf: measure four balanced process pairs per benchmark - #1635
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
mrousavy
force-pushed
the
codex/perf-four-balanced-pairs
branch
from
September 7, 2026 19:32
376e2ae to
15c760f
Compare
Performance Report
iOS
All Benchmarks
AndroidNo observed change reached the 5% reporting threshold. All Benchmarks
Benchmarking Code Diff Raw measurements: performance-report-1 (JSON artifact). Run 34155950400, attempt 1. Download requires GitHub access. Android: measurements, attempt 1, apps, attempt 1. |
mrousavy
marked this pull request as ready for review
September 8, 2026 10:39
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.
Each benchmark currently gets one base/head process pair, so one slow launch can dominate the PR comparison. Measure four adjacent pairs per case in AB, BA, BA, AB order, with a fresh process for each launch and each revision first twice.
Build and install each app once, retain the existing five warmups and twenty measured batches per process, and preserve all four numbered base/head runs and per-case JSON. HEAD report generation requires the declared pair count and correct identities, pools all four runs using the existing median calculation, and still accepts retained one-pair measurements from earlier attempts. The table layout and reporting threshold are unchanged.
The one-second app-start sleep was already removed by #1616. Two initial animation frames and five warmups remain; the one-second Android crash-monitor interval runs concurrently. With 46 cases, measurement uses 368 fresh processes per platform. Reducing the sample budget or sharding cases across runners can be evaluated separately.
Validation after rebasing onto the merged #1623 reporting pipeline: 103 performance-tool tests passed, including exact process order and lifecycle on both controllers, same-binary reuse, changed/reordered/unequal suites, all-four-pair reporting, missing/duplicate/extra results, and retaining an earlier iOS measurement while rerunning Android. Package builds, tooling/app typechecks and app lint passed.
The same-binary CI diagnostic passed on both Blacksmith platforms at
376e2ae93f32b0326112b948e2909f91f4b7f729. Downloaded base/head app artifacts were byte-for-byte identical. The raw report artifact passed this revision's reporter against GitHub's actual run/artifact metadata. All 736 process results followed the intended order with matching work counts and twenty samples each.These are descriptive results from one same-binary job per platform, not a calibrated false-positive rate or a regression gate. Remaining apparent differences are measurement variation.
The diagnostic ran before #1623 merged. The current PR is rebased onto that reporting pipeline and applies the four-pair reader in
generate-report.ts; publication-envelope validation stays unchanged. Replaying the diagnostic's complete raw artifact through the rebased generator produced byte-identical Markdown and Android/iOS BMF to the original validated report. The controller's execution order is unchanged by the rebase.The historical diagnostic's separate publishing run failed because main switched to requiring
performance-publication-1while the older workflow produced onlyperformance-report-1. The diagnostic measurements and local report validation succeeded. The rebased PR now produces the publication artifact using HEAD code, so its report can be reviewed before merge. Same-branch manual diagnostics are not main history and should not upload to Bencher.