Skip to content

perf lab: add exact comparison twins and the MessagePipe semantic ledger #507

Description

Part of #500. Blocks #414. Depends on #506 for the canonical profile.

Question

For every DxMessaging-versus-MessagePipe row, can we measure the same topology and account for every semantic difference before interpreting the rate ratio?

Mechanism

A comparison can reward fewer handlers, different token topology, different payloads, fragmentation, or less lifecycle work. Without exact internal twins and a semantic ledger, the observed gap mixes implementation cost with contract differences.

Contract

Keep the public comparison idiomatic for both libraries. Benchmark-only normalized rows may remove one documented semantic cost at a time, but they never become production APIs or replace the public-contract result.

The ledger covers ordering, live activity, callback-time mutation visibility, snapshot timing, reset, reentrancy, exceptions, diagnostics, registration lifecycle, reclamation, thread ownership, and found/not-found behavior. Mark each dimension matched, extra, or absent.

Factors and workloads

  • GlobalToOne, GlobalToMany, KeyedToOne, and the exact comparison struct.
  • Filtered, PostProcess, and FilteredPostProcess.
  • Canonical SubUnsub lifecycle.
  • 16 tokens/handlers and 16 distinct targets with one hit.
  • One token with four priorities.
  • One interceptor, one post, and one interceptor plus one post.
  • Targeted, broadcast, without-context, and global-accept-all siblings where applicable.
  • MessagePipe physical-capacity fragmentation: one survivor at first, middle, and last slots; alternating holes; repeated churn while retaining one subscriber.
  • Callback-time subscribe and dispose traces for both libraries.

Record handler count, token count, priorities, route cardinality, payload shape, live count, physical capacity, mutation, diagnostics, allocation work, and cleanup work.

Primary response

The fraction of public comparison rows with both a machine-verified exact internal topology twin and a complete semantic-ledger entry.

Independent unit

One comparison row for coverage. Performance confirmation uses independent clean IL2CPP build pairs; rows, launches, and cycles remain nested observations.

Effect threshold

Acceptance requires 100% twin and ledger coverage. Any unmatched dimension prevents a parity claim for that row. A movement beyond 3% is material but cannot be attributed until both validators pass.

RED proof

  • First require the existing 16-token/16-handler internal row for GlobalToMany in ComparisonDispatchTopologyTests; the stale four-handler mapping must fail.
  • Change a twin's token, handler, priority, payload, or route cardinality and prove validation fails.
  • Delete a required ledger dimension and prove schema validation fails.
  • Break callback fan-out or teardown reconciliation and prove exact assertions fail.
  • Use a stale external package version or source hash and prove validation fails.

GREEN suites

Pass bridge tests, internal twins, exact fan-out assertions over warm-up plus all emitted operations, source/version pin validation, allocation and lifecycle checks for SubUnsub, renderer/schema tests, and the canonical Standalone comparison suite.

Stop rule

If a public-contract twin is impossible, document why and add a benchmark-only normalized lower bound. Do not manufacture equivalence, hide extra work, or use the normalized row alone to close #414.

Immutable evidence

Retain topology manifests, semantic ledger, MessagePipe version/source hashes, raw cycles, callback totals, live/physical capacity, allocation/lifecycle results, rendered tables, and public-versus-normalized mappings.

Dependencies

Timing conclusions also depend on #508 for content-addressed evidence and #510 for calibrated inference.

Completion checklist

Activity

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions