Voici un résumé structuré de la vidéo intitulée "The ultimate Rust performance guide" de la chaîne Let's Get Rusty :
- Le piège de l'optimisation précoce : L'auteur rappelle la célèbre phrase de Donald Knuth selon laquelle l'optimisation précoce est la racine de tous les maux [00:53]. Le problème n'est pas d'optimiser, mais d'optimiser les mauvaises choses.

- La méthode : Il faut d'abord mesurer les performances pour identifier où l'application passe son temps (les 3 % critiques), isoler le goulot d'étranglement, puis optimiser [01:15].

Pour illustrer le profilage, la vidéo prend l'exemple d'un outil CLI synchrone qui analyse des fichiers de logs HTTP contenant 1 million de lignes [02:13].
Les outils présentés incluent :
- Hyperfine : Un outil en ligne de commande pour réaliser des benchmarks et établir une base de référence temporelle [02:49].

- Cargo Flame Graph : Génère un graphique (Flame Graph) au format SVG pour visualiser précisément dans quelles fonctions le CPU passe son temps [03:12].
(Note : il faut activer les symboles de débogage dans le profil de release pour pouvoir le lire [03:31]).
[profile.release] debug = true
- dhat : Un profileur de tas (heap profiler) pour analyser les allocations de mémoire et traquer le gaspillage de ressources [04:17].
[dependencies] dhat = "0.3.3" [features] dhat-heap = []
Génère un fichier au format JSON Vous pouvez analyszer les deux fichiers générés précédement (#[cfg(feature="dhat-heap")] #[global_allocator] static ALLOC: dhat::Alloc = dhat::Alloc; fn main() { ... let _profiler = dhat::Profiler::new_heap(); ... }
dhat-heap.json,flamegraph.svg) par une IAPrompt : Analyze these performance files and help me identify bottlenecks
Pour le code asynchrone (Async Rust), trois autres outils sont mentionnés [05:17] :
- Tracing : Un framework de diagnostic pour collecter des événements structurés [05:23].
- Tokio Console : Permet d'avoir une vision en temps réel de l'exécution des tâches asynchrones [05:38].
- Oha : Un outil CLI de test de charge pour les points de terminaison HTTP [05:45].
La vidéo applique le cycle d'optimisation sur l'analyseur de logs pour montrer des gains concrets :
-
Éviter les algorithmes/structures inefficaces [06:14] : *
- Problème isolé : Le programme initial appelait
.collect::<Vec<_>>()sur chaque ligne splitée, créant 1 million de vecteurs inutiles (consommant 500 Mo de mémoire et beaucoup de CPU) [06:56]. - Solution : Remplacer le
collectpar un parcours direct via l'itérateur [07:38]. - Résultat : Le temps passe de 460 ms à 300 ms (gain de 35 %) et l'empreinte mémoire chute de 80 % (de 500 Mo à 100 Mo) [08:19].
- Problème isolé : Le programme initial appelait
-
Éliminer le travail inutile [08:46] :
-
Paralléliser le travail avec Rayon et DashMap [09:37] :
- Technique : Utiliser la bibliothèque
Rayonpour transformer les itérateurs séquentiels en itérateurs parallèles, etDashMappour une table de hachage concurrente ultra-rapide [09:51].
[dependencies] rayon = "1.10" dashmap = "6.1"
- Résultat : Le temps final tombe à 200 ms [11:08].
Techniques d'optimisation
- Generics over Dynamic dispatch
- Inline critical functions
- CoW smart pointers
- Rayon & Dashmap
- Technique : Utiliser la bibliothèque
Bilan de performance global [11:14]
En appliquant ces étapes, l'application est passée de :
-
Temps d'exécution : 460 ms
$\rightarrow$ 200 ms (une amélioration de 56,5 %) -
Mémoire utilisée : 500 Mo
$\rightarrow$ 100 Mo (une réduction de 80 %)

