8000 Bench: migration timing across scale, browsers and pinned readers · Issue #838 · project-minigraf/minigraf · GitHub
[go: up one dir, main page]

Skip to content

Bench: migration timing across scale, browsers and pinned readers #838

Closed

Description

@adityamukho

Completed — 2026-11-04

Implemented in #851 (merged into v3) and project-minigraf/minigraf-docs#89 (merged). Published report, frozen fixtures, raw results and reproduction protocol.

All five acceptance criteria are satisfied within the maintainer-approved bounded scope: all nine native fixtures through 200k facts; Chromium, Firefox and WebKit at 2k/20k facts; separate migration/read-only/reopen controls; supported post-migration snapshot churn. The report retains 810 checked timing samples, 117 separate untimed checks, both native sessions and their variance, exact fixture bytes/hashes, build/runtime provenance and explicit exclusions. Benchmark scratch has been removed.

The exploratory 200k-fact browser observation is untimed and excluded from measured coverage by explicit scope decision. Cold startup, broader browser lifecycle and sustained many-pin/RSS/quarantine-byte scaling remain documented exclusions coordinated with X04/X06, not outstanding acceptance work for this bounded sweep. X03 remains MANUAL; no nightly coverage is promoted.

Original scope and completed checklist

Follow-up of #776: X03 in the remaining exclusions and follow-ups table, finalized in #834.

Disposition: MANUAL migration.

Milestone: v3.next — This is a broader future migration timing sweep beyond the verified small native representative, not a new nightly release acceptance route.

Remaining scope recorded by the audit:

Native migration uses one small frozen v7 fixture, not a large dictionary/scale sweep. Browser migration and migration with pinned-reader churn have no V timing; IndexedDB open/write coverage is not migration coverage.

C07 selects open/storage_v3/{migrate_v7,read_only_v7}/multi_checkpoint. It uses one small frozen v7 multi-checkpoint corpus and validates every manifest query; copying is outside timed open. Read-only v7 is nonmigrating and must not be reported as migration. This establishes a native representative, not large dictionary/scale behavior.

Remaining work is a native v7-to-v8 sweep with larger dictionaries and fact/value distributions, browser migration timings, and migration/persistence scenarios involving pinned-reader churn where supported. Document actual supported reader lifetimes rather than implying an impossible concurrent migration contract. Browser indexeddb_write/1k and indexeddb_reopen/1k only measure write-through/reopen in the same page/context, not migration or cold startup. Coordinate browser churn timing with X04 and sustained pin scaling with X06.

Why outside the nightly shortlist: growing migration fixtures and host-specific IndexedDB/pinned-reader scenarios need a separate manual sweep; ordinary open/write representatives cannot certify these distinct costs.

Acceptance criteria:

  • Define and publish a pinned native migration fixture ladder, including larger dictionary cardinalities and repeated/unique long values, with exact fact counts and expected results.
  • Measure native v7-to-v8 migration separately from read-only v7 open, keeping fixture copies/setup outside timing and verifying migrated data and reopen results.
  • Measure browser migration independently of IndexedDB open/write, recording browser/runtime, core/binding revisions, persistence setup and correctness checks.
  • Exercise supported pinned-reader/churn migration or persistence scenarios; record explicit unsupported combinations and snapshot/pin correctness checks.
  • Publish timings, scaling, fixture/build/runtime metadata and remaining exclusions without promoting unmeasured cases to nightly coverage.

Run heavy builds, enumeration, measurements and comparisons on idle hardware; retain reproducible evidence and clean temporary scratch afterward. This is benchmark/verification work aligned with PHILOSOPHY.md's reliability, portability and simplicity principles; any production change needs its own review.

Evidence: docs/bench-coverage-v3.md; validation run 41642356471. The validation run establishes only its recorded representative latency coverage; it does not complete this follow-up.

Activity

  1. added this to the v3.next milestone on Nov 4, 2026
  2. added a commit that references this issue on Nov 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    migrationMigration related issueperformanceBenchmark performance regressions

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0