Cas d’usage de WASM : traitement d’images et calcul

La chaîne standard de traitement des images avec WASM consiste à obtenir un objet ImageData depuis un canevas, à convertir ses données de pixels en tableau typé (Uint8Array), à les copier dans la mémoire linéaire de WASM, à appeler la fonction WASM pour appliquer le filtre, à recopier le résultat et à utiliser putImageData() pour afficher l’image traitée sur le canevas.

Les comparaisons de performances montrent systématiquement que les implémentations WASM des filtres de niveaux de gris et de flou sont 5 à 10 fois plus rapides que leurs équivalents JavaScript sur les grandes images. Pour une image de 4000 × 3000 pixels, un filtre de niveaux de gris JavaScript peut prendre 80 ms, tandis que la version Rust compilée en WASM s’exécute en moins de 10 ms. Cette différence est perceptible par les utilisateurs dans les scénarios de retouche en temps réel.

Le traitement audio en temps réel utilise AudioWorklet de l’API Web Audio, qui s’exécute dans un fil d’exécution audio dédié, distinct du fil d’exécution principal. WASM peut s’exécuter dans un AudioWorklet pour produire des effets audio presque natifs (réverbération, compression, égalisation). Cela contourne entièrement React pour le traitement audio : React ne gère que les commandes de l’interface qui configurent les paramètres audio.

Papa Parse gère bien l’analyse des CSV en JavaScript pour les fichiers de petite ou moyenne taille, mais pour les fichiers contenant des millions de lignes, un analyseur CSV Rust compilé en WASM est nettement plus rapide. L’analyseur WASM traite le tableau d’octets bruts, applique le filtrage et la transformation en Rust, puis ne renvoie à JavaScript que le résultat traité, évitant ainsi la création de millions d’objets JavaScript intermédiaires.

Pour effectuer rapidement des recherches en texte intégral dans de grands documents (fichiers journaux, bases de code, grands jeux de données), un moteur d’expressions régulières Rust compilé en WASM offre des performances de recherche presque natives. Des bibliothèques comme la bibliothèque Rust regex, compilées en WASM, peuvent parcourir des millions de lignes en quelques millisecondes. React affiche les résultats de recherche ; WASM effectue la recherche.

Les fonctions de hachage cryptographique (SHA-256, SHA-512) et le chiffrement symétrique (AES) implémentés en Rust WASM offrent des performances rapides et déterministes, indépendantes des optimisations du moteur JavaScript. Pour les applications qui effectuent un chiffrement côté client (messagerie chiffrée de bout en bout, dérivation de mots de passe avec Argon2), les bibliothèques cryptographiques basées sur WASM sont nettement plus performantes que les implémentations entièrement en JavaScript.

Le moteur physique Rapier (rapier.rs) est écrit en Rust et compilé en WASM, ce qui le rend disponible pour les jeux dans le navigateur et les simulations interactives. React affiche l’interface du jeu et les panneaux d’état ; le module WASM de Rapier exécute la simulation physique à chaque image. Ce modèle sépare clairement les préoccupations liées à l’interface de celles liées au moteur de jeu.

Du point de vue de React, les fonctions WASM sont de simples fonctions de calcul : elles reçoivent des données d’entrée et renvoient des résultats. React les appelle, reçoit les résultats et met à jour l’état : const result = await runWasm(inputData); setState(result). React effectue un nouveau rendu pour afficher les résultats. Cette séparation claire permet de conserver un code de composant simple, quelle que soit la complexité du calcul.

L’exécution d’un calcul WASM synchrone sur le fil d’exécution principal de React bloque le navigateur : aucune mise à jour de l’interface, aucun traitement des événements ni aucune animation ne peuvent avoir lieu avant la fin du calcul. Pour toute opération WASM qui prend plus de 16 ms (une image à 60 images par seconde), déplacez le calcul dans un Web Worker. React communique avec le Worker par des messages et met à jour l’état lorsque les résultats arrivent.

Lorsque vous transmettez de grands tableaux entre JavaScript et WASM, évitez les copies lorsque cela est possible. Accédez directement à la mémoire linéaire de WASM via l’memory.buffer ArrayBuffer, écrivez les données d’entrée à l’aide de vues sur des tableaux typés (new Uint8Array(wasmMemory.buffer, offset, length)), appelez la fonction WASM et lisez les résultats dans le même tampon. Ce schéma sans copie est essentiel pour les grands tampons d’images et audio.

Les algorithmes de compression Brotli et Zstd compilés en WASM permettent une compression rapide côté client. Dans les applications React, ils peuvent servir à compresser de grandes charges utiles JSON avant leur envoi afin d’économiser de la bande passante, à décompresser des formats de données binaires provenant du serveur pour les afficher et à créer des applications riches capables de fonctionner hors ligne en stockant des données compressées dans IndexedDB.

Pourquoi faut-il déplacer les calculs WASM de longue durée vers un fil d’exécution Web ?

WASM excelle dans la manipulation des pixels (5 à 10 fois plus rapide que JS pour les filtres d’image), l’audio en temps réel dans AudioWorklets, l’analyse de fichiers CSV ou texte volumineux, les opérations cryptographiques et la simulation physique. Le modèle React est simple : React appelle WASM comme une fonction de calcul pure, puis affiche les résultats. Exécutez toujours les calculs qui durent plus de 16 ms dans un fil d’exécution distinct afin de libérer le fil principal. Utilisez des techniques sans copie, comme un ArrayBuffer partagé, pour transférer les gros volumes de données en limitant les frais supplémentaires.