Goal
Evaluate whether Bun's upcoming engine-native bun:ffi implementation can outperform srcmap's current WASM and Node-API paths for hot, fine-grained source-map operations.
Bun's engine-native FFI pull request introduces JavaScriptCore CallFFI nodes, direct native calls from optimized code, and lower per-symbol memory usage. Its reported gains grow with FFI-call density. The pull request is not released yet, and Bun still documents bun:ffi as experimental.
Candidate surfaces
SourceMapGenerator.addMapping and maybeAddMapping, which repeatedly pass primitive integer arguments
SourceMap.originalPositionFor, using an opaque map handle and a caller-owned flat result buffer
- Batch position lookup as a control, where boundary overhead should already be amortized
Do not start with coarse operations such as full parsing, codec conversion, or remapping. Their native work and string transfer are likely to dominate the call boundary.
Proposed experiment
After a stable Bun release contains the engine-native implementation:
- Add a minimal C ABI behind an experimental build path, with explicit create/free functions and opaque handles.
- Keep the existing WASM and Node-API backends unchanged.
- Expose the Bun path explicitly during the experiment rather than selecting it automatically.
- Compare JavaScript, WASM, Node-API, and Bun FFI using the existing source-map benchmarks.
- Validate against a real Bun workload with repeated lookups or mapping generation.
- Measure latency, throughput, memory, initialization cost, and handle cleanup.
- Verify correctness parity on the existing fixtures and supported Bun platforms.
Decision criteria
Keep the backend only if it produces a meaningful end-to-end improvement on a released Bun version without weakening correctness, portability, or memory safety. Close the experiment if the gain exists only in synthetic call-overhead benchmarks or does not beat the current WASM path.
References
Goal
Evaluate whether Bun's upcoming engine-native
bun:ffiimplementation can outperform srcmap's current WASM and Node-API paths for hot, fine-grained source-map operations.Bun's engine-native FFI pull request introduces JavaScriptCore
CallFFInodes, direct native calls from optimized code, and lower per-symbol memory usage. Its reported gains grow with FFI-call density. The pull request is not released yet, and Bun still documentsbun:ffias experimental.Candidate surfaces
SourceMapGenerator.addMappingandmaybeAddMapping, which repeatedly pass primitive integer argumentsSourceMap.originalPositionFor, using an opaque map handle and a caller-owned flat result bufferDo not start with coarse operations such as full parsing, codec conversion, or remapping. Their native work and string transfer are likely to dominate the call boundary.
Proposed experiment
After a stable Bun release contains the engine-native implementation:
Decision criteria
Keep the backend only if it produces a meaningful end-to-end improvement on a released Bun version without weakening correctness, portability, or memory safety. Close the experiment if the gain exists only in synthetic call-overhead benchmarks or does not beat the current WASM path.
References
benchmarks/sourcemap.mjsbenchmarks/sourcemap-wasm.mjspackages/generator/src/lib.rspackages/sourcemap/src/lib.rs