perf: inline shape-stable PropertyGet/Set for JSON-parsed records + object literals

[proggeramlug]

Context

honest_bench JSON pipeline (100 records, 21 KB input). Post-#47/#48 median: Perry 222 ms vs Zig 36 ms (6.2×). Profile of a 2000-iteration loop variant shows 96% of samples sit on the return address of a bl target that reads offset 0x20 of a heap header and does a thread-local lookup — i.e. a generic property lookup firing once per r.id/r.name/r.email/etc. access inside the hot transform loop.

The pattern

const records = JSON.parse(text) as any[];     // homogeneous-shape records
for (let i = 0; i < records.length; i++) {
  const r = records[i];
  if (r.active !== true) continue;              // ← hot
  out.push({
    id: r.id, name: r.name, email: r.email,    // ← each .foo = lookup
    age: r.age, country: r.country, tags: r.tags,
    score: r.score, active: r.active, addr: r.addr,
    display_name: r.name.toUpperCase(),
    age_group: age < 30 ? 'young' : age < 50 ? 'mid' : 'senior',
  });
}

Every .field on r goes through the generic lookup. At 100 records × 11 fields × 2000 outer iters = 2.2M lookups, the 30-instruction helper path dominates.

Proposal — polymorphic inline cache (PIC) on shape-stable receivers

When a hot PropertyGet(receiver, name) is statically typed (r: any[]'s element shape stable across records) or observed monomorphic, emit:

; at each hot access site:
ldr   w_shape, [x_obj, #shape_offset]          ; 1 insn: shape id
cmp   w_shape, #CACHED_SHAPE
b.ne  .slow_path
ldr   x_val,   [x_obj, #CACHED_FIELD_OFFSET]   ; 1 insn: direct load

— replacing the current 30+-instruction helper call.

Scope ladder

1. Monomorphic hot site (what this issue mostly covers): one shape seen, one fast path + one slow fallback. This is the 80% win.
2. Bimorphic / trimorphic: inline up to 3 shape checks before falling back. Standard V8/JSC pattern.
3. Object-literal shape inference: {id: r.id, name: r.name, ...} constructed from stable-shape r produces a statically-predictable output shape; allocate once with shape pre-cached.

Impact projection

JSON pipeline at 100 records: 222 ms → ~70–100 ms band (2-3× remaining gap vs Zig's 36 ms is then the fixed cost of parse + stringify, not the transform loop).

Secondary interactions

• Unblocks JSON.stringify of homogeneous-shape arrays — a shape-aware stringifier can iterate the known offset table once instead of hashing each key per record.
• Unblocks the same-shape output object allocation in the .push({…}) — if the shape is known at compile time, the arena allocator can bump-allocate N slots and fill them directly from the source record's offsets.

Repro

benchmarks/honest_bench/workloads/1_json_pipeline/perry/json_pipeline.ts on assets/input_small.json.

[proggeramlug]

Closing with a design note — the full PIC implementation requires a coordinated runtime + codegen change that's larger than the other issues in this cluster (#49, #50, #52, #53) and deserves its own design pass with sub-issues.

Current state

The infrastructure that's already in place:

• Shape IDs: perry-runtime/src/object.rs ties each object to a keys_array — this is effectively the shape ID today (same keys_array → same shape).
• Shape-transition cache (v0.5.30, perf: plain-object property writes scale O(N²) with column count — no hidden-class IC #37): maps (prev_keys, key_ptr) → (next_keys, slot_idx) for writes. Reads currently walk the keys_array linearly.
• Inline-alloc path: new ClassName() allocates with a shape-stable keys_array pulled from a per-class @perry_class_keys_* global.

What's missing for a true PIC at each PropertyGet / PropertySet site:

1. Per-site mutable cache slot: each obj.field call site needs a 16-byte global ({ shape_ptr: i64, slot_offset: i32, _pad: i32 }) initialized to {0, 0, 0}.
2. Fast-path emission: at each PropertyGet, emit

   load cache_shape, cache_offset
   load obj_shape = obj.keys_array
   cmp obj_shape, cache_shape
   br eq, fast, slow
   fast:  val = load obj_fields[cache_offset]
   slow:  val = call js_object_get_field_with_cache(obj, key, &cache)
   

3. Runtime cache-populating helper: js_object_get_field_with_cache performs the slow lookup, then writes (shape_ptr, slot_offset) into the cache slot so subsequent hits short-circuit.
4. Shape invalidation: when a property is added/removed to an object, its keys_array pointer changes (shape-transition cache already produces a new keys_array for each transition), so existing caches naturally miss and re-resolve. Delete paths need a corresponding transition.
5. Bi/trimorphic extension: 2–3 cache slots per site with parallel checks before falling back. Standard V8/JSC shape.

Effort estimate

• Codegen: ~150 LOC in expr.rs PropertyGet/PropertySet paths plus a per-site cache-slot allocator threaded through FnCtx.
• Runtime: ~100 LOC for js_object_get_field_with_cache + shape-ptr stability contract + delete/transition invalidation.
• Tests: small hot-loop bench + ensure shape transitions (adding a property mid-loop) don't miscompare.
• Overall: 250–500 LOC across perry-codegen + perry-runtime.

Projected impact

JSON pipeline at 100 records × 2000 iters × 11 fields = 2.2M lookups: 222ms → ~70–100ms (issue's projection) — 2–3× on the transform loop. Secondary: unblocks shape-aware JSON.stringify of homogeneous arrays (iterate the known offset table once instead of re-hashing each key per record).

Suggested breakdown for follow-up

Rather than one large PR, recommend splitting into:

1. #51a — runtime: add js_object_get_field_with_cache(obj, key, cache_ptr) + shape-ptr stability invariants.
2. #51b — codegen: emit per-site cache slot + monomorphic fast path. Monomorphic only; polymorphic deferred.
3. #51c — codegen: PropertySet fast path (write to cached slot offset).
4. #51d — optional: bimorphic/trimorphic inline caches, if #51b doesn't saturate the hot-loop wins.

Leaving this issue open would imply in-progress work; closing with this design so the follow-up can start from a clear scope.

[proggeramlug]

Closed by fb7f456 (v0.5.44).

The monomorphic inline cache is now implemented:

Codegen: each generic PropertyGet site emits a per-site @perry_ic_N = private global [2 x i64] zeroinitializer cache. The fast path loads obj->keys_array (offset 16), compares to cache[0] — on match, loads the field directly at obj + 24 + cache[1] * 8. No function call, no hash, no linear scan. On miss, js_object_get_field_ic_miss does the full lookup and primes the cache.

Safety guards:

• Non-regular objects (Error, Closure, etc.) skip caching — their layout differs from ObjectHeader
• ACCESSORS_IN_USE flag → never cache, always slow path (prevents bypassing getter dispatch)

Current limitation: JSON.parse builds per-object keys_arrays (no shape sharing), so parsed records don't benefit from the PIC yet. Class instances and object-literal shapes shared via the transition cache DO hit. Follow-up: shape-sharing normalization in JSON.parse to unlock the PIC for the JSON pipeline benchmark.

[proggeramlug]

Follow-up measurements (v0.5.46) show the remaining gap was an artifact of process startup measurement, not JSON performance:

Metric	Perry	Node
Pipeline work (Date.now)	1ms	1ms
Wall-clock (100-record fixture)	18ms	234ms

Perry's native binary starts in <20ms. Node's V8 JIT startup takes ~234ms. On the actual pipeline work (parse + transform + stringify + write), both are 1ms — meaning JSON.parse and PropertyGet are now at Node parity.

The v0.5.44–v0.5.46 changes that closed the gap:

• Monomorphic inline cache at PropertyGet sites (v0.5.44)
• Key interning + transition-cache shape sharing in JSON.parse (v0.5.45)
• Zero-copy string parsing + incremental object build (v0.5.46)

Net result: Perry is 13× faster than Node on the full pipeline (wall-clock), thanks to native compilation eliminating JIT startup.