2026年最新版：WebAssemblyランタイムのパフォーマンスを徹底比較

2026年現在、WebAssembly（Wasm）ランタイムの性能はどのような進化を遂げたのか。主要なランタイムの実行速度やメモリ消費量など、エンジニアが今知るべき最新のベンチマーク動向をまとめました。次世代の高速なWebアプリ開発に最適なランタイム選びの参考にしてください。

メモリ使用量がわかると嬉しいな。理想を言えば、ベースの使用量、次に単体を1つ動かした時のコスト、その次に50個動かした時のコストが見たい。個人的にはネイティブと比べて速度が50%程度なら、そんなに悪くないと思う。今まで長年PerlやJava（v4～v7の頃）、Nodeなどを使ってきたけど、これらはどれもネイティブより劣る部分があって、それでもみんな許容してきたわけだし。理想はもちろんWasmがもっと速くなることだけど、2倍の遅さなら十分許容範囲だよ！

ここでNodeの速度が遅いことを見るに、最適化を強制せずに実行したんじゃないかな。NodeはOSR（On-stack replacement）を行わないから、ベンチマーク用のスクリプトだとベースラインコンパイラからフル最適化された層へ段階的に上がる機会がないんだよね。「node --no-liftoff」を付けて実行すればこの問題を回避できるよ。（これはコードがイベントループに戻る必要があり、最適化が働きやすいWeb上では問題にならないことで、Nodeも元々そういうワークフロー向けに最適化されてるんだ）

WASMランタイムにとって、int8のドット積や角度/コサイン距離なんかはかなり正体を暴くようなマイクロベンチマークになるね。（私が作った）NumKong [1] には、通常のAVX2/HaswellとAVX2-VNNI/Alder Lakeの両方をターゲットにした実装があるから、ランタイムやコードジェネレーターがどこでパフォーマンスの最適化をサボってるのかがすごくわかりやすいよ。これについてWasmtime/CraneliftのPRをいくつか立て始めたんだけど、最後までやりきれなかったんだ。バックエンドやコード生成の作業に興味がある人には、楽しい週末プロジェクトになるかもね。

WASMランタイムがサンドボックス環境でありながらネイティブコードに近づいているのは本当に素晴らしいことだけど、これらのベンチマークは「ランタイム本体＋GC＋標準ライブラリ」をサンドボックス内に丸ごと含めていないという前提である点には注意が必要だね。

ずっと昔にWasmerへの入社面接の準備をしていた時、彼らがLinuxのカーネルエクステンションとしてWasmerを動かすことで、処理速度を4桁（1万倍）速くしたことを見せてくれたんだ。WASIがある今、Wasmerのようなツールのプラグインとしての利便性以上に、WASMが全てのオペレーティングシステムで「第2のバイナリ」として受け入れられない理由は何なんだろう？とずっと考えてる。例えばWindowsがexeだけでなくwasmもサポートすれば、ついに真のクロスプラットフォームバイナリが手に入るわけだし。Appleは絶対認めないだろうけど、Microsoftならやるかもしれないし、Linuxなら単純に実装できるでしょ。

https://r-carissimi.github.io/wasure/ にもっと包括的なベンチマークがあるよ。かなり違う結果が出ているはず。ちなみにlibsodiumは数値演算がかなり重いんじゃなかったかな。

Rust版のWAVMってこと？WAVMはまだARM MTEやRISC-V CHERIをサポートしていないよね？wasmtime-mteもベンチマークに追加した方がいいかも。

wazeroと比べて自分のwasm2goがどんな立ち位置になるのか気になるな。自分でテストしてみないと。:)