perf: OpenCode native binary startup must beat the bun binary — attribute and remove the module-init cost (measured 13× bun CPU on the Aug 21 build)

[proggeramlug]

Parent: #10107. Related: PERRY_STARTUP_PLAN.md (PR #10066 tiny-path work), #6532/#6533/#6534 (cc --version 227 ms), #9441 (idle tail), scavenge/tenuring notes.

Measured 2026-09-12 (dev Mac, load avg ~100 — wall inflated; CPU is the fair number)

binary	--version wall	user CPU	max RSS
official bun-compiled opencode 1.17.7	1.0–1.5 s	0.54 s	185 MB
bun run src/index.ts --version (transpiles on the fly)	2.8 s	0.85 s	—
perry Aug-21 binary (minimal profile, 2,454 modules, 213 MB, perry 0.5.1512)	15–29 s	6.8–7.0 s	563 MB
same, --help	14.8 s	7.0 s	—
A sample of the stripped binary shows the main thread 100 % in generated code (no wait states), i.e. eager module initialization of the graph (Effect's 225 modules build Schema/Layer/Context objects at import; drizzle tables; yargs command tree). No startup number exists for the full graph (4,063 modules on v1.18.30; 7,136 on the Windows full build #9133), so expect worse before optimization.

Target

On the quiet Mac mini (perry@perry-macos.local), same host, five warm runs each, paired A/B per PERRY_STARTUP_PLAN S1 discipline:

• opencode --version: user CPU ≤ 0.5 s, wall ≤ 1.0 s, RSS ≤ 185 MB (beat the official v1.18.30 binary from gh release download v1.18.30 -R anomalyco/opencode -p 'opencode-darwin-arm64.zip').
• opencode --help and TUI time-to-first-frame: below bun.

Scope

1. Attribute: symbols build (strip=none, PERRY_MAIN_STACK_MB if needed), sample/Instruments over --version, plus PERRY_DEBUG_INIT module-init trace; produce a per-module init-cost table (top 50) and a per-runtime-helper table (class registration, closure allocation, object-literal construction, string interning, regex compile — regex construction is eager and SipHash-keyed per pattern in perry, see the regex analysis note in secret-tests memory, GC minors during init).
2. Lazy work: anything perry does per module that bun does not (e.g. eager class/shape registration, module-global slot promotion, side-table setup) becomes lazy or batched; check the young-gen / tenuring configuration during init (563 MB RSS vs 185 MB suggests allocation volume, not just code size).
3. Graph-level: confirm the compiled graph does not initialize modules bun would never evaluate (dynamic-import-only subgraphs such as Code Mode/typescript, prettier, @babel/* via the runtime Solid plugin — must not be in the eager init order; fix(compile): support full OpenCode source builds #9133 kept dynamic imports out of eager init, verify on this graph).
4. Binary size / page-in: 213 MB → the first-run variance (16→29 s) hints at page-in; measure cold vs warm and consider PERRY_LL_SIZE_OPT=1 + optnone threshold (perf(compile): reduce generated bundle bloat #8418) trade-offs.
5. Re-measure after each lever with the A/B script; keep raw samples in secret-tests/opencode-1.18.30-inventory/perf/.

Acceptance

• Attribution report with the top-50 module-init costs and the runtime-helper breakdown, on the full v1.18.30 graph.
• --version user CPU and RSS below the official bun binary on the Mac mini, two independent batches.
• TUI first frame not slower than bun.
• No correctness regressions: the 22 node startup oracles (PERRY_STARTUP_PLAN) and the cc --help parity gate stay green.

[proggeramlug]

Startup attribution, first hard number (2026-09-13, before the symbols profile)

The --help family is not init cost: it is string-width. yargs 18 formats help through cliui → string-width@7.2.0, and a 9-module perry probe calling stringWidth() on three typical help lines 3,000 times each (9,000 calls) takes

	perry (linux-x64, --no-auto-optimize)	bun 1.3.14
9,000 stringWidth() calls	340,204 ms (≈38 ms per call)	72 ms

GC is not the issue there (share_permille=13, arena 0.4 MB) — it is pure CPU inside the width computation: string-width 7 iterates every grapheme with Intl.Segmenter and, per grapheme, tests emojiRegex() (constructs the ~14 KB emoji regex inside the loop, once per character) plus /^\p{Default_Ignorable_Code_Point}$/u. A finer probe separating regex construction, regex .test, the segmenter and strip-ansi is running; whichever it is, this single path explains opencode --help at 31 s / run --help at 20 s (the time scales with help text) and is the first lever for this ticket. The 1.6 GB live arena seen under PERRY_GC_DIAG on --help is a separate observation to attribute with the symbols build.

[proggeramlug]

Finer attribution of the string-width cost (perry vs bun per operation): emojiRegex() construction 631 µs vs 2.3 µs (274×), reused .test 11 µs vs 0.4 µs (28×), strip-ansi replace 14 µs vs 0.1 µs (143×), Intl.Segmenter line 68 µs vs 12 µs, eastAsianWidth 10×. Construction per grapheme dominates. Filed as #10179.

[proggeramlug]

perf profiles on the debug-symbols build (linux-x64, perf record -F 499 -g)

--help (27 s user): regex construction and matching plus the GC they cause.

• perex compiler (Parser::escaped_point 7.1 %, Parser::sequence 7.0 %, class_atom 2.9 %, Prepared::emit 3.1 %, builtin/leaf/join 4.5 %, Program::from_words 1.2 %) ≈ 26 % — that is new RegExp(<14 KB emoji pattern>) compiled once per grapheme by string-width (perf(regexp): constructing a RegExp recompiles the pattern every time (14 KB emoji-regex: 631 µs vs 2 µs in bun, 274×) — string-width makes opencode --help cost 31 s #10179, PR perf(regex): cache compiled programs and speed up test/replace #10193).
• perex executor (input::Cursor::next_unit) 10.6 % — matching that regex per grapheme.
• GC (ArenaObjectCursor::next_budgeted 8.8 %, trace/classifier/root-marking/layout/sweep steps ≈ 20 %) ≈ 30 % — the allocation volume of those compiles (PERRY_GC_DIAG: 89 cycles, 1.6 GB live arena).
  PR perf(regex): cache compiled programs and speed up test/replace #10193 removes the first two buckets (string-width 47.9 ms → 0.46 ms per call in the lane's measurement) and most of the third.

--version (2.0 s user): flat, no single hot symbol. Top entries are generic by-name property access during module initialization — get_field_by_name_object_tail 2.3 %, keys_find_slot_by_bytes 1.9 %, shape_descriptor_ensure_with_holes 1.7 %, js_object_get_field_by_name 1.6 %, get_accessor_descriptor 1.2 % — plus core::str::from_utf8 1.7 %, GC layout/trace bookkeeping ≈ 6 %, js_array_get_f64/js_array_length 1.8 %. In other words: 7,897 module initializers (#10180) each doing dictionary-style property reads and writes on freshly built objects, not one pathological site. The levers are the module count (#10180) and cheaper object construction/property access in init code (shape-known stores instead of by-name lookups; from_utf8 on every string constant materialization is worth a look).

[proggeramlug]

Status 2026-09-13 evening: --help fix PR #10193 (regex construction cache, stringWidth 41.8 ms → 0.39 ms) is rebased onto 0.5.1557 and waiting for the merge train; the module-pruning ask #10180 (7,897 → toward bun's 4,063 modules, the main lever on the 1.9 s --version init cost) has a codex lane on it. Current numbers on perrymaster with the pinned compiler: --version 1.9 s user (bun 0.35), --help 28 s (bun 0.37), models --help 6.7 s.