Skip to content

perf(vapor): compile the three GB sdcc translation units in parallel - #394

Open
lfkdsk wants to merge 2 commits into
pocket-stack:mainfrom
lfkdsk:fleet/vapor-gb-parallel-sdcc
Open

perf(vapor): compile the three GB sdcc translation units in parallel#394
lfkdsk wants to merge 2 commits into
pocket-stack:mainfrom
lfkdsk:fleet/vapor-gb-parallel-sdcc

Conversation

@lfkdsk

@lfkdsk lfkdsk commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

What

buildGbRom compiled its three sdcc translation units serially (vapor/compiler/rom.ts). The compiler stage is the bulk of a GB build — the Pocket Vapor compiler itself is ~6% of wall clock, typescript.js load ~43%, external toolchains ~48% — so this runs the three units concurrently and keeps the link order unchanged.

Measured

before (median) after (median) delta
full --target gb build 3108 ms 1847 ms −40.6%
three-unit sdcc stage alone 2721 ms 1592 ms −41.5%

Sample ranges do not overlap (serial min 3073 ms > parallel max 1882 ms). The stage is now bounded by the slowest unit (gen_app, ~1.6 s). On a single core the gain disappears (+1%), as expected.

Correctness

  • All three .rel files, crt0.rel, the intermediate app.ihx and the final todo.gb (32768 B) are byte-identical to the serial build across 5 consecutive parallel builds.
  • Parallelizing needed two failure-handling fixes beyond the scheduling change, because Promise.allSettled does not abort on the first failure the way the serial await loop did: failures are collected and re-thrown naming the unit, and the second commit (from the cross-family review) additionally removes partial .rel outputs and the stale final ROM on failure and preserves stdout-only diagnostics in link order.
  • New vapor/tests/gb-build.test.ts with an sdcc shim (per-unit delay, partial-output and stdout-only failure injection); seven guard-removal mutations each fail a distinct case. bun test vapor/tests/: 77 pass / 0 fail.

Known limitation (pre-existing, not introduced here)

Two different apps building --target gb into the same output directory at the same time race on the shared gen-gb intermediates; this was observable before this change and is left for a follow-up.

Provenance

Autonomous fleet run: Scout-measured candidate (report on the fork branch lfkdsk/pocketjs:fleet/scout-compile-time), Builder implementation, cross-family review that hardened failure handling on top.

🤖 Generated with Claude Code

@lfkdsk
lfkdsk force-pushed the fleet/vapor-gb-parallel-sdcc branch 2 times, most recently from e7a1437 to 845b5a3 Compare September 8, 2026 21:18
lfkdsk and others added 2 commits September 8, 2026 14:19
The units have no compile-time dependency and write distinct outputs, so
dispatching them together cuts a full --target gb build from a median of
3108 ms to 1847 ms (-40.6%, n=15 each). All three .rel files, crt0.rel,
app.ihx and todo.gb stay byte-identical to the serial build across 5 runs.

Failures now have to be collected rather than thrown by the first await:
report the failing unit in link order with sdcc's stderr attached, and
delete the target .rel files up front so a stale one from an earlier build
can never reach the link step.

Co-Authored-By: Claude Code <noreply@anthropic.com>
Co-authored-by: TRAE CLI <traecli@bytedance.com>
@lfkdsk
lfkdsk force-pushed the fleet/vapor-gb-parallel-sdcc branch from 845b5a3 to 07ce66b Compare September 8, 2026 21:20
@lfkdsk

lfkdsk commented Sep 8, 2026

Copy link
Copy Markdown
Contributor Author

Rebased onto current main (061c6be) and dropped the fork-only base commits, so the PR now contains only its own commit(s). bun test vapor/tests/ on the rebased branch matches main in this environment: everything passes except the NES parity build, which fails identically on unmodified main here (local ld65/cc65 library mismatch).

@lfkdsk
lfkdsk marked this pull request as ready for review September 8, 2026 23:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant