Mog Performance: Rust + WebAssembly vs. JavaScript Spreadsheets

Why Performance Matters for Spreadsheets

Spreadsheets look simple on the surface, but they are deceptively compute-intensive. A financial model with 10,000 formulas needs to recalculate its entire dependency graph every time a cell changes. Importing a 10MB Excel file means parsing millions of XML nodes and materializing cell values. Rendering a viewport of 1,000 cells at 60fps means producing a new frame every 16.6 milliseconds.

For small spreadsheets, any engine is fast enough. But as sheets grow — and they always grow — performance becomes the difference between a responsive tool and a frustrating one. Users notice when recalculation takes 500ms instead of 10ms. They notice when opening a file takes 8 seconds instead of 1.

Mog's Architecture Advantages

Mog's performance story starts with the choice to build the compute core in Rust and compile it to WebAssembly for the browser. This gives us several structural advantages over JavaScript-based engines:

Compiled, optimized code. Rust compiles to machine code (or WASM bytecode) with LLVM optimizations. Formula evaluation runs in tight loops over typed data without the overhead of JavaScript's dynamic dispatch, hidden classes, or JIT warmup.

Predictable memory layout. Cell data is stored in contiguous, typed arrays rather than JavaScript objects scattered across the heap. This means better cache locality and no garbage collection pauses during computation.

Binary wire protocol. Instead of serializing cell data to JSON for rendering (which allocates strings and objects), Mog streams a binary buffer directly to the canvas layer. Each cell record is a fixed 32 bytes, read directly from a typed array with zero intermediate allocations.

Parallel-ready architecture. Rust's ownership model makes it safe to parallelize formula evaluation across dependency graph partitions. While we have not yet enabled multi-threaded WASM (waiting on broader browser support), the architecture is ready for it.

Engineering Targets

Based on our architecture and internal testing, we are targeting the following performance benchmarks for the initial release:

| Benchmark | Target | Context | |-----------|--------|---------| | 10K formula recalc | < 10ms | Full dependency graph recalculation | | 10MB XLSX parse | < 1s | Client-side, in the browser via WASM | | Cold start | < 1.5s | WASM download, compile, first render | | Viewport render | < 2ms | 1,000 cells, binary protocol to canvas |

These targets are derived from our architectural measurements and internal profiling, not from independent third-party benchmarks.

An Honest Disclaimer

We want to be transparent: Mog is pre-launch, and these are engineering targets, not independently verified benchmarks. We have measured these numbers in controlled environments during development, but real-world performance depends on many factors: device hardware, browser version, WASM engine optimizations, file complexity, formula distribution, and more.

We have not yet run systematic, reproducible benchmarks against other libraries under controlled conditions. Claiming "10x faster than X" without rigorous methodology would be misleading, and we will not do it.

What We Are Measuring

We are building a benchmarking harness that will measure:

• Formula evaluation throughput — recalculation time for sheets of 1K, 10K, 50K, and 100K formulas with varying dependency complexity
• File I/O speed — parse and write times for XLSX files of 1MB, 10MB, 50MB, and 100MB with different content profiles
• Rendering frame time — time to produce a frame for viewports of 100, 500, 1,000, and 5,000 visible cells
• Memory footprint — peak memory usage for workbooks of varying size
• Cold start latency — time from page load to interactive spreadsheet, including WASM compilation

We plan to publish these benchmarks with full methodology, reproducible scripts, and comparisons to popular open-source libraries. When we do, the numbers will be verifiable by anyone.

For the latest benchmark data and methodology details, see the Benchmarks page.