🚧 Attention, peinture fraîche !

Cette page a été traduite par une seule personne et n'a pas été relue et vérifiée par quelqu'un d'autre ! Les informations peuvent par exemple être erronées, être formulées maladroitement, ou contenir d'autres types de fautes.

Réduire la taille des .wasm

Pour les binaires .wasm que nous distribuons aux clients à travers le réseau, comme notre application du Jeu de la vie, nous voulons veiller à la taille du code. Plus notre .wasm sera petit, plus vite notre page se chargera rapidement, et plus nos utilisateurs seront satisfaits.

A quel point nous pouvons diminuer la taille des binaires .wasm avec la configuration de la compilation ?

Prenez un moment pour consulter les options de configuration de compilation que nous pouvons activer pour obtenir du code .wasm plus petit

Avec la configuration de compilation par défaut pour la publication (sans les symboles de débogage), notre binaire de WebAssembly fait 29 410 octets :

$ wc -c pkg/wasm_jeu_de_la_vie_bg.wasm
29410 pkg/wasm_jeu_de_la_vie_bg.wasm

Après avoir activé le LTO, avoir réglé opt-level = "z", et lancé wasm-opt -Oz, le binaire .wasm qui en résulte est réduit à seulement 17 317 octets :

$ wc -c pkg/wasm_jeu_de_la_vie_bg.wasm
17317 pkg/wasm_jeu_de_la_vie_bg.wasm

Si nous le compressons avec gzip (ce que fait presque tout serveur HTTP), nous arrivons à une taille minuscule de 9 045 octets !

$ gzip -9 < pkg/wasm_jeu_de_la_vie_bg.wasm | wc -c
9045

Exercices

  • Utilisez l'outil wasm-snip pour enlever les fonctions de l'infrastructure de panique sur le binaire .wasm de notre jeu de la vie. Combien d'octets cela économise ?

  • Compilez notre crate du Jeu de la vie avec et sans l'allocateur global wee_alloc. Le gabarit rustwasm/wasm-pack-template, que nous avons cloné pour démarrer ce projet, avait une fonctionnalité "wee_alloc" que vous pouvez activer en l'ajoutant à la clé default dans la section [features] de wasm-jeu-de-la-vie/Cargo.toml :

    [features]
    default = ["wee_alloc"]
    

    Quelle taille we_alloc économise sur le binaire .wasm ?

  • Nous n'avons instancié qu'un seul Univers, donc au lieu de fournir un constructeur, nous pouvons exporter des opérations qui travaillent sur une instance globale static mut. Si cette instance globale utilise aussi la technique de double buffering que nous avions évoqué dans les chapitres précédent, nous pouvons aussi rendre globaux ces tampons avec static mut. Cela enleve toute la partie d'allocation dynamique de notre implémentation du Jeu de la vie, et nous pouvons la transformer en crate #![no_std] qui ne contient pas d'allocateur. Quelle taille a été économisé sur le .wasm en enlevant complètement cette dépendance à l'allocateur ?