All benchmarks run on a 100,000-row, 10-column workbook. Node.js, single thread.

The heavy lifting — ZIP decompression, XML parsing, shared string table lookup, and style resolution — runs in compiled WASM at near-native speed. The WASM sandbox also provides memory safety guarantees.

Data crosses the WASM boundary as a JSON string (serialized with serde_json in Rust, parsed with JSON.parse in JS). This is 8-13x faster than serde_wasm_bindgen for large workbooks because:

1. JSON serialization in Rust is heavily optimized (itoa, ryu)
2. JSON.parse is one of the fastest built-in JS operations
3. Avoids thousands of individual WASM boundary crossings

The Rust core uses quick-xml in SAX (streaming) mode rather than building a DOM tree. This keeps memory usage proportional to the current element being processed, not the entire document.

When writing, the shared string table is built and indices are remapped inline during XML generation — avoiding a full worksheet clone that earlier versions required.

Use aoaToSheet / jsonToSheet instead of setting cells one by one:

// Fast — batch API
const ws = aoaToSheet(data);
// Slower — individual cell access
for (const [r, row] of data.entries()) {
 for (const [c, val] of row.entries()) {
 ws.cell(encodeCellRef(r, c)).value = val;
 }
}

Use sheetRows to limit how many rows are parsed:

const first100 = sheetToJson(ws, { sheetRows: 100 });

Call initWasm() once at startup, not before every operation:

// Good
await initWasm();
// ...later, many operations...
// Bad — redundant (safe but wasteful)
await initWasm();
const wb1 = await readFile('a.xlsx');
await initWasm(); // unnecessary
const wb2 = await readFile('b.xlsx');

The WASM binary is loaded asynchronously and can be cached by the browser/runtime. The JS code is tree-shakable — unused utilities are eliminated by bundlers.