[perf] DataView accessors, Array.concat, and regex match-with-groups are 4–30x slower than Hermes

[dlee]

What happened

Three hot operations each lower to an opaque js_* runtime helper and land well
behind the Hermes interpreter. Perry 0.5.1220 vs Node v22 (V8) vs Hermes 1.0.0
(built from main), best of 5, macOS arm64; identical checksums across engines.

Op	Perry	Node	Hermes	Perry/Hermes
DataView set/getFloat64 (300×4096)	205 ms	1 ms	34 ms	6x
Array.prototype.concat (20000×1024)	686 ms	11 ms	23 ms	30x
regex .match() w/ 4 groups (300k)	237 ms	12 ms	67 ms	~3.5x

Regex matching without extraction (RegExp.test()) is separately fast — the
cost is in materializing capture arrays / accessor results, i.e. the helper
call, not the regex engine.

What you expected

At least Hermes-interpreter throughput on these ops.

Minimal reproduction

// DataView — 6x
function dv() { var N=4096, b=new ArrayBuffer(N*8), v=new DataView(b), a=0;
  for (var r=0;r<300;r++){ for(var i=0;i<N;i++) v.setFloat64(i*8,i*1.5+r,true);
    for(var i=0;i<N;i++) a+=v.getFloat64(i*8,true);} return Math.round(a); }

// Array.concat — 30x (arrays built once, concat isolated)
function cc() { var N=512,x=[],y=[]; for(var i=0;i<N;i++){x.push(i);y.push(i+N);}
  var a=0; for(var r=0;r<20000;r++){ a+=[].concat(x,y).length; } return a; }

// regex match with capture groups — ~3.5x
function rm() { var s="2026-07-13 key=42 val=99", re=/(\d{4})-(\d{2})-(\d{2}) key=(\d+)/, a=0;
  for (var i=0;i<300000;i++){ var m=s.match(re); if(m) a+=m[1].length+m[4].length; } return a; }

perry compile x.js -o x && ./x     # vs node x.js / hermes -O x.js

Environment

• Perry version: 0.5.1220
• Host OS: macOS 27.0 (arm64)
• Target: native
• Installed via: npm

Diagnostic output

DataView   perry 205ms | node 1ms  | hermes 34ms   (chk=3957657600 all)
concat     perry 686ms | node 11ms | hermes 23ms   (chk=20480000 all)
regexMatch perry 237ms | node 12ms | hermes 67ms   (chk=1800000 all)

Anything else

Likely instances of #6082 (helper declarations carry no LLVM attributes),
filed with per-op repros so each has a regression target — as typed-array
access got in #5525.

[proggeramlug]

Confirmed on current main (0.5.1258, release, macOS arm64). Three notes — the last one changes the framing.

Still reproduces; no regression since you filed

Measured back-to-back on one machine (so the numbers are comparable to each other, not to yours — my host is ~1.7x slower than yours on node):

op	perry v0.5.1255	perry main 0.5.1258
DataView set/getFloat64	477 ms	428 ms
Array.prototype.concat	1191 ms	1139 ms
regex .match() w/ 4 groups	631 ms	617 ms

So it hasn't drifted — the recent type-inference and codegen work neither fixed nor worsened it.

The gap vs Node is far larger than the gap vs Hermes

On my host, same run:

op	perry	node 26	perry/node
DataView	428 ms	2 ms	214x
Array.concat	1139 ms	13 ms	88x
regex w/ groups	617 ms	22 ms	28x

Your table leads with Hermes (6x / 30x / 3.5x), which understates it. Hermes is a bytecode interpreter and is itself 20-30x behind V8 on these; being "only 6x behind Hermes" on DataView means being ~200x behind V8. Worth stating so the target isn't set too low.

Your diagnosis looks right, and it already has a tracking issue

Three hot operations each lower to an opaque js_* runtime helper

That is exactly #6082 — runtime helper declarations carry no LLVM attributes, so -O3 cannot CSE, LICM, or otherwise optimize across a js_* call. Its first tranche landed in #6283, but that annotated 9 of 2858 declarations (0.3%) — the read-only/type-check/nanbox families only. js_dataview_*, js_array_concat, and the regex capture-materialization helpers are all still bare, which is precisely the "opaque helper" wall you hit.

Two caveats from that work, so nobody re-derives them the hard way:

• memory(argmem: read) is unsound for Perry — helper args are f64 NaN-boxes, not LLVM pointer args, so LLVM reads argmem as empty and licenses CSE/DSE across real heap reads. Use memory(read).
• willreturn on any js_throw-reachable helper lets DCE delete a throwing call whose result is unused — try/catch is setjmp/longjmp, not LLVM unwind — silently swallowing the exception.

The DataView case may also compound with #5525-family cost (per-access typed-array kind lookup), which is worth checking separately.

I'd suggest this issue stays as the concrete, measured instance and #6082 as the mechanism. Thanks for the careful benchmark — the "test() is fast, match() is slow" isolation was the useful clue.