WASM It Worth It? Calling Rust from R

Published on November 1, 2026 by Viliam Simko

Calling Rust code from R introduces a choice: should we use a WebAssembly runtime, embed a JavaScript engine, or load a native Rust library? Each option has a different balance of portability, performance, and runtime footprint.

To make that trade-off concrete, this experiment compares three ways of exposing the same Rust function to R: V8 + WebAssembly, Wasmtime + WebAssembly, and native Rust via extendr. The shared function comes from a small component of corrplot-ng, but the focus here is on the integration approaches—not the application itself.

WebAssembly is often presented as the universal escape hatch: compile your code once, run it almost anywhere, and keep the platform-specific glue to a minimum. But does that portability come at a measurable cost?

So, WASM it worth it?

I built a small experiment around the same Rust function and compared all three approaches. The short answer: WebAssembly works, but in this particular R integration native Rust is faster and much smaller. Wasmtime is a credible middle ground; V8 pays a noticeably higher per-call cost in this prototype.

These are engineering measurements for one workload and integration setup, not a universal ranking of runtimes.

Three roads from R to Rust

All three approaches expose the same Rust function, corrplot_core::validate_matrix, to R. Using one implementation and identical JSON fixtures keeps the comparison focused on the integration path rather than differences in the underlying algorithm.

1. V8 + WebAssembly. The R package’s V8 engine loads the host-neutral WASM module. R communicates with JavaScript, which then crosses the WASM boundary.
2. Wasmtime + WebAssembly. R calls Wasmtime through a small C shim. Wasmtime loads the same WASM module and executes the Rust core.
3. Native Rust + extendr. R calls a platform-native Rust library through extendr, without a WebAssembly runtime.

A pure-R implementation is included as a reference baseline. It is not a fourth Rust integration strategy.

The important control is that the three Rust backends call the same core implementation and use the same JSON fixtures and contract. The experiment is about the integration path—not three independently written versions of matrix validation.

What exactly did we measure?

The CI benchmark uses six deterministic fixtures:

• valid-small
• valid-general-32 (32×32)
• valid-general-128 (128×128)
• valid-general-512 (512×512)
• valid-correlation-64 (64×64)
• invalid-asymmetric

Each platform runs the same fixtures through V8 + WASM, Wasmtime + WASM, native Rust + extendr, and a pure-R reference implementation. The R runners warm up, calibrate the batch size, and collect ten timed samples. The reported value is the mean milliseconds per call, accompanied by a 95% confidence interval calculated from those ten within-run samples; lower is better.

The measurements include the complete R-to-backend path, including host/ABI and JSON conversion overhead. They are not measurements of the isolated Rust function. This distinction matters: a runtime can execute WASM quickly and still lose time moving values between R, JavaScript, C, and linear memory.

The current successful CI run covers three x86-64 architectures/platform combinations: Ubuntu Linux, Intel macOS, and Windows with the GNU/MSYS2 toolchain. It does not cover ARM64. The Linux and macOS runners report R 4.6.2; the Windows size-reporting script did not emit its R version.

The confidence intervals describe variation between timed samples on one CI runner. They do not represent variation between independent CI runs or different machines. Treat the numbers as directional measurements for this integration setup, not universal runtime rankings.

Results across three x86-64 platforms

Each cell shows the mean in milliseconds per call followed by its 95% within-run confidence interval. The four implementations share the same Rust validation contract and JSON fixtures; pure R is a reference baseline, not a Rust integration strategy.

Source run and downloadable data. All performance tables in this section use corrplot-ng workflow run #41404373498. All three platform jobs completed successfully. Each uploaded artifact contains a benchmark.csv with the six fixture results for all four backends, plus the corresponding fixture JSON outputs: Ubuntu Linux x86-64 artifact, Intel macOS x86-64 artifact, and Windows x86-64 artifact. That is 24 backend/fixture means per platform (72 across the three platforms), covering 18 fixture/platform combinations. The tables below match these uploaded CSVs. The checked-in report and CSV snapshot are older results and are not the source for the published numbers.

Ubuntu latest — Linux x86-64

macOS 15 Intel — Darwin x86-64

Windows latest — x86-64 / GNU toolchain

What stands out

• Native Rust is the fastest implementation in every fixture on all three platforms. For the 512×512 general matrix, it takes about 5.8 ms on Linux and Windows, and 10.9 ms on Intel macOS. It is roughly 1.6–2.2× faster than the faster WASM route on that fixture.
• Wasmtime usually beats V8, particularly on small and medium inputs. The exception is the Windows 512×512 case, where V8 takes 10.04 ms and Wasmtime 12.61 ms.
• The pure-R reference is slower in this specific JSON validation benchmark, with the gap growing sharply for larger matrices. This is not a claim that R is generally slow: it compares this reference implementation and boundary against a shared Rust core.
• The confidence intervals are narrow in many Linux and Windows cases, but wider on macOS, especially for longer calls. They quantify within-run sample variation only; overlapping intervals should not be interpreted as a formal cross-machine significance test.

The useful lesson is not simply “native is fastest”. It is that the cost of crossing boundaries can dominate a small operation. The more work each call performs, the easier it becomes to amortize that fixed cost.

The runtime can be much bigger than the module

The WASM module itself is small: about 144 KiB on all three platforms. The host runtime is the much larger part of the footprint.

These are different artifact categories, not directly comparable end-user download sizes: the V8 figure is an installed R package directory, Wasmtime is a shared library, the Rust figure is a standalone native shared library, and the WASM figure is the module file alone. They do, however, illustrate an important practical point: a tiny portable module does not make its runtime free.

The native-library values in this table come from a separate controlled size workflow and are exact standalone cdylib measurements. That workflow also measured the legacy generated R package:

The current native cdylib is smaller than the legacy installed native library on Linux and Intel macOS, but larger on Windows in this run. The current native build uses matching linker debug-stripping settings on Linux and macOS; Windows remains unstripped. This is not a strict like-for-like package comparison: the legacy generated package uses extendr 0.9.0, while the current native crate declares extendr 0.8 as its Cargo semver requirement. The current adapter is not yet a separately installable R package, so there is no matching installed-package or source-tarball figure for it. The source archive in the table is for the legacy R package.

Native Rust has a small measured library artifact, but it comes with a different distribution obligation: build and ship the right native binary for each supported platform.

The controlled size workflow used Rust 1.99.1, Cargo 1.99.1, and R 4.6.2 on all three runners. Its target triples were x86_64-unknown-linux-gnu, x86_64-apple-darwin, and x86_64-pc-windows-gnu. The legacy generated package used extendr 0.9.0; the current native crate declares extendr 0.8 as its Cargo semver requirement and resolves to extendr-api 0.8.2 in Cargo.lock. For the current native cdylib, CI used -C link-arg=-Wl,--strip-debug on Linux and -C link-arg=-Wl,-S on macOS, and no strip flag on Windows. The legacy generated-package workflow separately records CORRPLOT_REXTENDR_STRIP_DEBUG=true; the JSON manifests include the R compiler and shared-library linker settings for each runner.

See the controlled binary-size experiment and the successful three-platform size workflow run #41428503394, with its Ubuntu artifact, Intel macOS artifact, and Windows artifact. These are the separate machine-readable sources for the installed-package and native-library footprint measurements; they should not be confused with the performance artifacts linked above.

What this experiment does not tell us

There are several gaps before these measurements could support a production decision:

• One CI run per platform. The 95% confidence intervals are based on ten timed samples within each run; there are no independent repeated runner trials or between-run confidence intervals.
• Warm calls only. Cold-start and first-call latency have not been measured.
• No memory profile. Peak resident memory and runtime initialization overhead still need measurement.
• x86-64 only. The current run covers Linux x86-64, Intel macOS x86-64, and Windows x86-64 with the GNU/MSYS2 toolchain. ARM64 is not covered.
• The JSON boundary is deliberate. The native adapter uses JSON too, so the comparison preserves a common contract. A typed R/native API might be faster, but would no longer be the same boundary comparison.
• The package footprint is incomplete. Full dependency closure, source package size, user download size, and installation experience need separate measurements.
• This is one operation, not a full application benchmark. It measures the shared matrix-validation boundary and synthetic fixtures, not corrplot rendering or end-to-end package workflows.

The full benchmark report and raw CSV are available in the experiment results at the exact source commit, alongside the successful three-platform CI run and draft experiment PR #239.

So, WASM it worth it?

For this particular workload and integration setup, the current numbers favour native Rust + extendr when throughput and a small runtime footprint are the main goals. Wasmtime + WASM remains interesting when distributing a host-neutral module or sharing one compiled artifact across multiple runtimes is more valuable than the extra runtime dependency. V8 + WASM is functional, but its current integration path usually has the largest per-call overhead.

That is not a universal verdict against WebAssembly. WASM remains useful for browser execution and for environments where a portable sandboxed module is the right deployment unit. The best boundary depends on the host, the workload, and what needs to be shipped.

This experiment provides a useful baseline for choosing how Rust code should be integrated into R. A broader evaluation would still need cold-start and memory measurements, ARM64 coverage, independent repeated CI trials, and a more complete view of packaging and maintenance costs.

If there is one takeaway, it is this: the fastest way to call Rust may be not to put another runtime between R and Rust—but portability can be worth paying for.

This is an exploratory benchmark of a shared validation function, not a production performance guarantee or a final corrplot-ng backend decision.