🚧 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.

Le profilage temporel

Cette section décrit comment profiler des pages web qui utilise Rust et WebAssembly dans le but d'améliorer le débit ou de réduire la latence.

⚡ Assurez-vous que vous utilisez toujours une compilation optimisée lorsque vous faites un profilage ! wasm-pack build devrait compiler avec les optimisations par défaut.

Les outils disponibles

Le chronomètre window.performance.now()

La fonction performance.now() retourne un chronomètre en millisecondes qui commence depuis que la page web a été chargée.

L'appel à performance.now n'a que très peu d'impact sur les performances, donc nous pouvons créer des mesures simples et granulaires grâce à elle sans impacter le reste du système et sans introduire de biais à ces mesures.

Nous pouvons l'utiliser pour chronométrer différentes opérations, et nous pouvons accéder à window.performance.now() via la crate web-sys :


#![allow(unused)]
fn main() {
extern crate web_sys;

fn now() -> f64 {
    web_sys::window()
        .expect("nous n'avons pas accès à l'objet `window`")
        .performance()
        .expect("nous n'avons pas accès à l'objet `window.performance`")
        .now()
}
}

Les profileurs des outils de développement

Tous les outils de développement intégrés dans les navigateurs web embarquent un profileur. Ces profileurs mettent en évidence les fonctions qui prennent le plus de temps à s'exécuter avec les outils de visualisation habituels comme les arbres d'appels et les flame graphs.

Si vous compilez avec les symboles de déboguage afin que la section personnalisée "name" soit ajoutée dans le binaire wasm, alors ces profileurs devraient afficher les noms des fonctions Rust plutôt qu'un nom obscur comme wasm-function[123].

Sachez toutefois que ces profileurs ne vont pas montrer les fonctions intégrées, et comme Rust et LLVM utilisent beaucoup de fonction intégrées, les résultats deviendraient compliqués.

Capture d'écran d'un profileur avec les symboles Rust

Ressources sur les profileurs web

Les fonctions console.time et console.timeEnd

Les fonctions console.time et console.timeEnd vous permettent de journaliser la chronologie des opérations demandées dans la console d'outils de développements du navigateur. Vous pouvez appeler console.time("le nom de l'opération") lorsque l'opération commence, et appeler console.timeEnd("le nom de l'opération") lorsqu'elle se termine. Le nom de l'opération est optionnel.

Vous pouvez utiliser directement ces fonctions avec la crate web-sys :

Voici une capture d'écran des journaux de console.time dans la console du navigateur :

Capture d'écran des journaux de console.time

De plus, les journaux de console.time et de console.timeEnd vont s'afficher dans les vues "timeline" ou "chronologie" du profileur de votre navigateur :

Capture d'écran des journaux de console.time

Utiliser #[bench] sur du code natif

De la même manière que nous pouvons tirer avantage des outils de déboguage de code de notre système d'exploitation en créant des fonctions #[test] plutôt que de déboguer sur le web, nous pouvons tirer avantage des outils de profilage de code de notre système d'exploitation en créant des fonctions #[bench].

Ecrivez vos tests de performance dans le sous-dossier benches de votre crate. Assurez-vous que votre crate-type inclut bien "rlib" ou sinon les binaires ne seront pas capables de se relier à votre bibliothèque principale.

Cependant, attention ! Assurez-vous d'abord que le problème de performance se trouve bien dans le WebAssembly avant d'investir votre temps dans le profilage du code natif ! Utilisez le profileur de votre navigateur pour vérifier cela, ou sinon vous risques de perdre votre temps à optimiser du code qui est potentiellement négligeable en termes de performance.

Ressources sur les profileurs natifs