perf: u8[i]/buf[i] on a Uint8Array or Buffer parameter is 53× slower than Node (out-of-line js_uint8array_get/set probing the buffer registries) #10515

Found by the package performance audit (real npm packages compiled from source, profiled against Node 26.5.1) and
re-measured on Perry 7661bc0 (v0.5.1589), Linux x64. Perry implements Uint8Array and Buffer as buffer-registry
objects, not as a typed-array kind. When the receiver is not a proven local (a parameter, a closure capture, or any
untyped value), no inline lane admits them. Every element read and write is then a runtime call that walks the
thread-local buffer registries.

nanoid's pool refill, buffer[i] = charCodes[buffer[i] & mask], is 114× slower than Node. The same loop over a
Uint16Array runs 5× fewer instructions than the Uint8Array version.

Reproduction

bench.ts (27 lines):

const variant = process.argv[2] || "u8"; const N = Number(process.argv[3] || "2000");
const ALPHA = "useandom-26T198340PX75pxJACKVERYMINDBUSHWOLF_GQZbfghjklqvwyzrict";
const L = 32768;
// nanoid customAlphabet pool refill: `buffer[i] = charCodes[buffer[i] & mask]`
function refillU8(b: Uint8Array, cc: Uint8Array): number { for (let i = 0; i < b.length; i++) b[i] = cc[b[i] & 63]; return b[7]; }
function refillU16(b: Uint16Array, cc: Uint16Array): number { for (let i = 0; i < b.length; i++) b[i] = cc[b[i] & 63]; return b[7]; } // CONTROL
function refillAny(b: any, cc: any): number { for (let i = 0; i < b.length; i++) b[i] = cc[b[i] & 63]; return b[7]; } // untyped params (plain .js)
function mk() { // nanoid shape: charCodes and `let mask` captured by the closure, Buffer pool
  const charCodes = Uint8Array.from(ALPHA, (s: string) => s.charCodeAt(0)); let mask = 63;
  return (b: Uint8Array) => { for (let i = 0; i < b.length; i++) b[i] = charCodes[b[i] & mask]; return b[7]; };
}
const clo = mk();
const cc8 = new Uint8Array(64), cc16 = new Uint16Array(64); for (let i = 0; i < 64; i++) { cc8[i] = ALPHA.charCodeAt(i); cc16[i] = ALPHA.charCodeAt(i); }
const pools: any[] = [];
for (let k = 0; k < 8; k++) {
  const p: any = variant.startsWith("u16") ? new Uint16Array(L) : variant.startsWith("u8") ? new Uint8Array(L) : Buffer.alloc(L);
  for (let i = 0; i < L; i++) p[i] = (i * 7 + k) & 255; pools.push(p);
}
function run(n: number): number {
  let acc = 0;
  for (let k = 0; k < n; k++) {
    const p = pools[k & 7]; p[0] = k & 255;
    acc = (acc + (variant === "u16" ? refillU16(p, cc16) : variant === "u16any" ? refillAny(p, cc16) : variant === "u8any" ? refillAny(p, cc8) : variant === "nanoid" ? clo(p) : refillU8(p, cc8))) % 1000000007;
  }
  return acc;
}
run(N / 5 | 0); const t0 = performance.now(); const cs = run(N); console.log(`${variant} checksum=${cs} ms=${(performance.now() - t0).toFixed(1)}`);

PERRY_NO_AUTO_OPTIMIZE=1 perry compile bench.ts -o bench
for v in u8 buffer nanoid u8any u16 u16any; do node bench.ts $v 2000; ./bench $v 2000; done   # "buffer" = Buffer via refillU8

Measurements

These are medians of 3 runs on a shared, loaded host. Instruction counts do not depend on host load, so they are the
reliable figure. The instruction totals are whole-process instructions:u and include the N/5 warm-up. The
per-element figure divides by 78.6 M element steps. N = 2,000 refills of a 32,768-element array.

Checksums are identical in all variants. Changing only the element kind from Uint16 to Uint8 costs 5× the instructions
with typed params and 6.6× with untyped params.

u8 profile (compiled loop 2.9 %):

u8any profile:

nanoid profile:

u16 profile: 93 % of samples are in the compiled loop (inline load and store).

Impact

Shares below come from the audit profiles taken on v0.5.1587.

• nanoid 6.0.0 (nanoid() ×10M, 48× Node):
  • Typed-array/Buffer element access is about 67 % of Perry time, and the polymorphic index get another 3.5 %. The
    objects-group attribution puts the construct at about 86 %.
  • Top self symbols: is_registered_buffer_slow 30.9 %, buffer_data 14.8 %, is_uint8array_buffer_slow 9.1 %.
  • The trigger is buffer[i] = charCodes[buffer[i] & mask] (index.js:100).
• uuid 14.0.1: typed arrays are 12 % of Perry time, about 23 % including dispatch (byteToHex[arr[i]],
  Uint8Array.of). is_registered_buffer_slow is 8.0 % self.
• @noble/hashes 2.2.0:
  • blake3: typed arrays are 27.0 % of Perry time (msg[offset + s[j++]] with a Uint8Array permutation parameter).
  • sha256: 17.4 %, together with perf: one ArrayBuffer-aliasing view anywhere, even a dead one, makes all typed-array access 81× slower than Node (process-global PERRY_TA_VIEW_GUARD) #10516. This figure is from the numeric-group profile.
• jsonwebtoken 9.0.3: 3–6 %.
• pg 8.22.0: is_registered_buffer_slow is 2.07 % self (io-group profile).

Mechanism

Verified unless marked (inferred).

• Declared Uint8Array/Buffer receiver.

  • lower_uint8array_get_i32 (crates/perry-codegen/src/expr/arrays_finds.rs:229-275) first tries
    lower_buffer_load (crates/perry-codegen/src/expr/buffer_access.rs:458).
  • That needs a tracked buffer-view descriptor for a local (lower_buffer_access_proof, buffer_access.rs:295-300). It
    also declines closure-captured buffers (buffer_access.rs:323). A parameter never has such a descriptor (inferred).
  • When the proof is missing, the lowering emits one call per element: js_uint8array_get (arrays_finds.rs:267) or
    js_uint8array_set (arrays_finds.rs:1129).

• The runtime path (js_uint8array_get, crates/perry-runtime/src/typedarray/access.rs:650-679). A
  lookup_typed_array_kind miss is the normal case for a Uint8Array. From there:

  1. is_registered_buffer (crates/perry-runtime/src/buffer/header.rs:485).
  2. is_registered_buffer_slow (header.rs:549): a thread-local RefCell<HashSet> probe plus the external and
     shared-SAB registries.
  3. js_buffer_get.
  4. buffer_data (header.rs:1274): view::lookup, plus the foreign_backing thread-local map (header.rs:1067).

  js_uint8array_set (access.rs:735) has the same shape.

• Why Uint16Array is fast. It is a real typed-array kind, so it gets the inline guarded element lane: kind cache,
  PERRY_TA_VIEW_GUARD, bounds check, load/store.

• Untyped receivers. js_packed_arraylike_index_get, js_dyn_index_get and js_dyn_index_set_strict ask the same
  registries, plus is_non_indexed_buffer_view, is_shared_sab and is_temporal_cell_addr, on every element (profile).

• nanoid's closure. The captured let mask turns b[i] & mask into js_dynamic_bitand (perf: bitwise operators on destructured, number-annotated or untyped values are 56× slower than Node (a js_dynamic_bit* call per operator, ToInt32 via software fmod) #10511). The captured
  charCodes read goes through js_object_get_index_polymorphic.

What fast looks like

• Inline byte lane. Give Buffer-backed Uint8Array/Buffer receivers a guarded inline byte load/store equivalent to
  the one Uint16Array already gets:
  • Guard on the tag.
  • Guard on the GC type, or on a Uint8Array brand in the header.
  • Guard on a "not a view / not foreign-backed" flag.
  • Guard on index < length.
  • Then load i8 / store i8 at header + size_of::<BufferHeader>().
  • Registry lookups happen only on the cold arm. This shape also removes the split classification that audit: lookup_typed_array_kind miss-consumers vs buffer-kind Uint8Array (split-brain classification, #9342 siblings) #9347 audits.
• Target: u8 and buffer at or below the u16 instruction count (≤ ~150 per element); u8any ≈ u16any.
  With perf: bitwise operators on destructured, number-annotated or untyped values are 56× slower than Node (a js_dynamic_bit* call per operator, ToInt32 via software fmod) #10511 also fixed, the nanoid refill should be ≤3× Node.

Notes

• audit: lookup_typed_array_kind miss-consumers vs buffer-kind Uint8Array (split-brain classification, #9342 siblings) #9347 (open) audits the correctness side of the same Uint8Array-is-a-buffer split: kind-registry misses treated
  as "not indexable". It does not track this element-access cost.
• perf(runtime): classify native-call receivers from the tracked header; no Buffer/typed-array registry probe for known kinds #9937 (open, draft PR) removes registry probes from native method-call receiver classification, not from element
  access.
• In-function Uint8Array reads are 12x slower than the identical top-level loop (560 vs 46 ms) — and the obvious fix returns wrong answers #9342 and perf: typed-array element access ~10x Node on BOTH paths (#5525's untyped/typed ratio is closed at 1.05) #8485 (closed) made reads inline for module-global and proven receivers. Parameters, captures and
  untyped receivers remain out of line.
• Other drafts: perf: one ArrayBuffer-aliasing view anywhere, even a dead one, makes all typed-array access 81× slower than Node (process-global PERRY_TA_VIEW_GUARD) #10516 is the whole-program typed-array deopt; perf: bitwise operators on destructured, number-annotated or untyped values are 56× slower than Node (a js_dynamic_bit* call per operator, ToInt32 via software fmod) #10511 is the dynamic &.