research: WASM core — evaluated and deferred (revisit if huge-file use case emerges)

[krkarma777]

Question

Would porting the Myers core to WASM (Rust or AssemblyScript) be worth it?

Assessment (2026-08-31, based on measured profiles)

Deferred. The numbers argue against it for the current positioning:

• Typical case (~1 ms): ~70% of time is tokenization + interning — Unicode property classification and string handling that stays in JS either way. The search itself is ~0.1 ms; nothing meaningful to accelerate.
• Boundary cost: strings must be copied/transcoded into WASM linear memory; for sub-millisecond diffs that copy rivals the entire current runtime. Well-JITed typed-array JS typically sits within 1.5–2x of WASM for this kind of kernel, so the ceiling is low.
• Worst case: already addressed algorithmically — heuristic: true took the 8 KB pathological case from 217 ms to 8 ms (27x). A plausible WASM 2x on exact mode (~110 ms) is strictly worse than the algorithmic fix.
• Cost side: bundle would grow from 2.9 kB min+gzip to tens of kB, instantiation becomes async (breaking the fully-sync API or forcing dual paths), and the toolchain lands on CI and contributors.

Revisit when

• A real use case for exact diffs of multi-MB inputs appears (copy cost amortizes), or
• A session-style API (load once, diff repeatedly) is on the table, or
• Someone wants to attempt bit-parallel Myers with WASM SIMD as a research spike.

Adoption bar, as with #19: prototype behind the existing middle-snake interface, benchmark against the JS core across all scenarios, adopt only on a clear win without regressing the typical case.