NetWasmは、C#および.NET Common Intermediate Language(CIL)をWebAssembly(Wasm)およびWebAssembly System Interface(WASI)コンポーネントに直接コンパイルするために設計された独立したツールチェーンです。標準的な.NET WebAssemblyの実装とは異なり、NetWasmはプロダクション用アーティファクトにデスクトップ用のCommon Language Runtime(CLR)、Mono、または巨大なアプリケーションDLLを含めません。その代わりに、コンパイラが到達可能なコードを特定し、アプリケーションに必要な特定のランタイムサポートのみをリンクする「クローズドワールド」コンパイルモデルを使用します。このアプローチにより、内蔵ランタイムと精密なCompactガベージコレクタを含む、スタンドアロンのWASI Preview 2コンポーネントを生成することが可能になります。

「print 42」のワークロードを比較した特定のベンチマークにおいて、NetWasmは47,895バイトの生のWasmコンポーネントを生成しました。これは、サイズ重視のプロファイルでコンパイルされたRust 1.95.0バイナリの53,635バイトを上回る結果です。Brotli-11を使用して圧縮すると、NetWasmのアーティファクトは13,660バイトまで減少したのに対し、Rustバイナリは16,963バイトと依然として大きなサイズを維持しました。このプロジェクトは、ジェネリクスの特化、ランタイムでの発見の代わりにJSONや依存性の注入(Dependency Injection)のための既知のコントラクトの使用、および動的なアセンブリのロードや「dynamic」キーワードのような広範なランタイム機能のプロファイルからの除外によって、これらの結果を達成しています。

NetWasm、Rust、Kotlin/Wasm、およびTinyGoのWebAssemblyフットプリントを、生のサイズとBrotli-11圧縮サイズの両方で比較した棒グラフ。
異なる言語間でのWebAssemblyバイナリサイズの比較。Rustや他のランタイムに対するNetWasmの効率性を強調。github.com

このチャートは、NetWasmが生のバイナリサイズと圧縮されたバイナリサイズの両方でRustを上回った特定のベンチマーク結果を視覚化したものです。

しかし、これらの結果は一般的な言語全体のランキングではなく、特定の測定されたワークロードを表すものです。NetWasmのプロファイルは意図的に制限されており、生のソケットやサブプロセスのような完全なシステムAPIをサポートしておらず、名前付き文化のグローバリゼーションやマネージドスレッドなどの多くの標準的な.NET機能を排除しています。さらに、NetWasmは標準的なBlazor WebAssembly(同様のワークロードで15メガバイトを超える可能性がある)と比較してフットプリントを大幅に削減していますが、依然として特殊なプラットフォームです。プロジェクトは現在プレ1.0の状態にあり、ロードマップは、安定した1.0リリースに到達する前に、WASI Preview 2のカバー範囲の拡大とインクリメンタルな開発ループの改善に焦点を当てています。

標準的なBlazor WebAssembly実装に対するNetWasmのフットプリントを示すサイズ比較チャート。
NetWasmのフットプリントは、同様のワークロードで15メガバイトを超える可能性がある標準的なBlazor WebAssemblyよりも大幅に小さい。github.com

この図は、標準的な.NET Blazor WebAssembly実装と比較してNetWasmによって達成された大幅なサイズ削減を例示しています。