BridgeJS: Optimize numeric array transfer with bulk TypedArray copy

[krodak]

Overview

Use bulk TypedArray memory copy instead of element-by-element stack serialization for numeric arrays ([Int], [UInt8], [Float], [Double], etc.). TypeScript types remain number[] / bigint[] — no user-facing API change.

This is a transparent performance optimization following the same pattern as bridgeJSStackPopAsOptional — the ABI changes internally but the type contract is unchanged.

How it works

Swift → JS (return values): Array.bridgeJSTypedArrayPush() calls withUnsafeBufferPointer → swift_js_push_typed_array(ptr, count, kind) → JS copies bytes into a TypedArray → pre-allocated for-loop converts to number[].

JS → Swift (parameters): [T].bridgeJSTypedArrayLiftParameter(sourceId, count) receives a retained TypedArray from JS → allocates via Array(unsafeUninitializedCapacity:) → calls back to JS via swift_js_init_typed_array_memory to bulk copy.

Non-numeric arrays ([String], [MyStruct], etc.) continue using the existing element-by-element stack protocol.

What changed

• BridgeJSSkeleton.swift — isNumericScalar and typedArrayKind helpers on BridgeType
• BridgeJSIntrinsics.swift — _BridgeJSTypedArrayElement protocol with 12 numeric conformances, extension Array where Element: _BridgeJSTypedArrayElement with bridgeJSTypedArrayPush() and bridgeJSTypedArrayLiftParameter(_:_:), WASM externs for swift_js_push_typed_array and swift_js_init_typed_array_memory
• JSGlueGen.swift — numericArrayLift, numericArrayLower, numericArrayLowerReturn JS fragment generators; routing to detect numeric arrays
• BridgeJSLink.swift — taStack, typedArrayConstructors, swift_js_push_typed_array, swift_js_init_typed_array_memory handlers
• ExportSwift.swift — Numeric array params use [T].bridgeJSTypedArrayLiftParameter(sourceId, count); returns use ret.bridgeJSTypedArrayPush()
• ImportTS.swift — Same pattern for imported function params/returns
• ClosureCodegen.swift — Numeric array closure params use bulk path

Benchmark results

Release build, 10K iterations × 5 runs:

Test	Before	After	Speedup
takeIntArray (1K, JS→Swift)	758 ms	13 ms	58×
takeDoubleArray (1K, JS→Swift)	791 ms	13 ms	61×
makeIntArray (1K, Swift→JS)	221 ms	18 ms	12×
makeIntArrayLarge (10K, Swift→JS)	2160 ms	146 ms	15×
makeDoubleArray (1K, Swift→JS)	271 ms	36 ms	7.5×
roundtripIntArray (1K)	964 ms	29 ms	33×
roundtripDoubleArray (1K)	1065 ms	29 ms	37×
takeStringArray (non-numeric)	23 ms	25 ms	unchanged

Follow-up

For users who want actual Uint8Array / Float32Array in their JS API (e.g., for fetch body, WebGPU), see PR #9 which adds JSTypedArray<T> as a recognized BridgeJS type.

[krodak]

Tracked in new PR against main repo