Skip to content

(OPT) Reuse certified first-head PLAN slices instead of rebuilding the right cursor view #902

Open

Description

@wsdt

Follow-up to #900 and #899: avoid rebuilding the right first-head segment view when the nested left first-head continuation already holds the same immutable segment. This targets singleton segments too. Discovery is source-only at local candidate d458d05 (production unchanged from 84432); no implementation, application admission or net gain is established.

In comparison_owner/paired_value.rs, preserve both preparations and every original left/right work event. In the fresh nonempty left-head continuation, pop the right link at its original boundary and compare the two lexical indices before indexing the right arena or constructing its slice/head/rest views. Equal indices in the same prepared immutable arena prove a nonempty identical segment: assign right_items from the already retained left post-head slice, advance the right item and enter #900's certified-head continuation. Foreign indices, loaded segments, exhaustion and tails retain complete ordinary behavior. No persistent certificate, pointer-content equivalence, preliminary walk or new authority.

Derive the final invoice from actual authored typed roles. Discovery layout: original right STEP+EMPTY=108 and LOAD=146; proposed BASE=36, POP=42, certified RHS=48 (including the retained 24-byte conservative as_ref invoice), foreign VIEW_HEAD=176 and loaded/exhausted HEAD=72. Thus ordinary branches remain fully priced, while a certificate removes an additional right arena/slice/head/rest packet beyond #900. A straightforward implementation adds four distinct primitive payment sites, acquired conservatively even when cold. Conditional complete-run equation on that layout: old900 minus successor = 128J - 4PAYMENT_HEADERM - 17(Qnew-Qold), before any further authored roles. Never add #900's separate 81*J or credit its as_ref roles twice. Foreign empty right segments can increase Q; refused prefixes require actual acquired-packet counts. These are a proposed component equation, not a projected application saving.

Splitting STEP changes real funding order: at the local boundary, 107 physical bytes and zero work may produce old physical refusal versus new work refusal. Specify that boundary honestly; preserve sticky failure and all six diagnostic fields at actual new sites. Do not pay a phantom old bank or assert unchanged mixed-budget priority. With sufficient physical funding, retain every original work cut, semantic result, ordering and heapsort swap.

Acceptance:

  • Freeze and independently compile the complete immediate predecessor, all macros and invoice; retain every older source/oracle/control. Couple new children to actual source unions using original classification tools.
  • Prove same-index first-head provenance, preparation/malformed-link/depth behavior and immutable same-invocation borrowing; preserve full independent final PLAN/HIR verification and both representations.
  • Derive all BASE/POP/HEAD/RHS, receiver/control/assignment/drop and cold-site invoices from final code. Census acquired versus completed certificates, Q events, fallback/empty cases and work; preserve surviving conservative fees, caps and hostile controls.
  • Exercise same/different IDs, equal contents in foreign IDs, empty/singleton/long segments, asymmetric entry, invalid histories, every work cut, exact/short/zero/floor/sticky/foreign/restored budgets, mixed byte/work cuts, post-swap behavior and complete allocation/reallocation/Drop.
  • Run the unchanged whole32 and real application owners at 67,108,864 bytes plus relevant focused checks and scoped production Clippy in a consolidated batch. Never full gates. Keep parents open where acceptance remains missing and distinguish shipping, synthetic and refused-prefix evidence.

Measurement attribution: the old352 trace with 62,710 rounds and 8,493 identity hits is rows.main in the whole32 fixture, not the normalizer application and not current J/G/Q. The separate old normalizer's committed route prefixes are not removable allocations. Neither proves current application ranking, token efficiency or billed-cost advantage.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions