Présentation de NetWasm

NetWasm 0.8.0 est un compilateur autonome qui transforme le code C# et le bytecode .NET CIL directement en modules WebAssembly compatibles avec l’interface WASI Preview 2. Le projet regroupe un CoreLib minimal, un runtime dédié et un SDK, éliminant la dépendance aux CLR de bureau, à Mono ou à dotnet.js. Cette architecture permet de produire des binaires autonomes, sans DLL d’application, ce qui réduit la surface d’empreinte du produit final.

Comparaison de taille avec Rust

Pour un programme de test « print‑42 », NetWasm génère un artefact de 47 798 octets. Le même workload compilé avec Rust 1.95.0, en mode profil orienté taille, atteint 53 635 octets. La différence brute représente 10,9 % de réduction. Après compression avec Brotli‑11, les tailles deviennent 38 000 octets pour NetWasm et 48 000 octets pour Rust, soit une amélioration de 20,4 %. Ces mesures incluent le runtime et le ramasse‑miettes compact précis fourni par NetWasm.

Analyse du runtime et du garbage collector

Le runtime intégré de NetWasm implémente un garbage collector compact à précision exacte, contrairement à la plupart des solutions .NET qui s’appuient sur le GC de Mono ou du CLR. Cette implémentation, conçue pour les environnements WASI, évite le chargement de bibliothèques supplémentaires et utilise un modèle de gestion de mémoire optimisé pour les tailles de page WebAssembly. Le fait de ne pas embarquer de DLL d’application réduit le nombre de sections ELF/WASI, ce qui se traduit directement dans la métrique de taille brute.

Limites et perspectives

Les chiffres présentés proviennent d’un seul benchmark (impression d’un entier). D’autres charges de travail, notamment celles nécessitant des bibliothèques tierces ou des appels système avancés, pourraient modifier le ratio de taille. De plus, la comparaison se base sur la version 0.8.0 de NetWasm et Rust 1.95.0 ; des évolutions futures de l’un ou l’autre des outils pourraient inverser la tendance. Enfin, la compatibilité WASI Preview 2 reste un facteur de restriction : les applications dépendant de fonctionnalités non encore stabilisées devront attendre des mises à jour du runtime.