perf(js): streamline exec response handling

[f0rr0]

Why

The public N-API /direct lane was spending much of its apparent Rust gap after execution, decoding the PostgreSQL wire response in JavaScript. A retained same-guest/same-runtime A/B reduced the raw Rust-to-N-API gap to 4.7% for 10k inserts and about 1% for indexed reads, isolating response handling rather than WASIX execution as the dominant remaining cause.

What

• parse wire fields directly into the final public result shape
• avoid intermediate raw-result objects, text-cell wrappers, and object spreads
• validate ordinary CommandComplete frames without allocating every command tag
• preserve managed-transaction tag materialization and all framing, UTF-8, notice, status, and decoder semantics
• keep generated JS/React Native/WASIX mirrors synchronized with the canonical shared implementation

Focused evidence

• actual retained N-API 50k INSERT response parsing: 55.79 ms -> 20.19 ms (-63.8%, -35.60 ms)
• 50k-tag readiness scan: 12.73 ms -> 5.49 ms (-56.9%, -7.25 ms)
• alternating scan A/B: 14.37 ms -> 7.83 ms (-6.55 ms)
• randomized equivalence: 100,000 response bodies matched baseline status/error behavior

Together these recover about 42 ms of the approximately 55 ms public N-API insert deficit in the supplied run. They do not claim to remove unavoidable JS object materialization or to change PostgreSQL/WASIX execution performance.

Focused qualification

• 19/19 shared parser tests passed
• generated mirrors are fresh
• strict canonical TypeScript check passed
• git diff --check passed

Broad release qualification is intentionally left to CI.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
oliphaunt-docs	Ready	Preview	Aug 30, 2026 10:57pm