README.md

Voici un résumé structuré de la vidéo intitulée "The ultimate Rust performance guide" de la chaîne Let's Get Rusty :

1. Le cycle de l'optimisation (Mesurer, Isoler, Optimiser)

• 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].

2. Outils de profilage recommandés (écrits en Rust)

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 = []

  #[cfg(feature="dhat-heap")]
  #[global_allocator]
  static ALLOC: dhat::Alloc = dhat::Alloc;
  
  fn main() {
      ...
      let _profiler = dhat::Profiler::new_heap();
      ...
   }

  Génère un fichier au format JSON Vous pouvez analyszer les deux fichiers générés précédement (dhat-heap.json, flamegraph.svg) par une IA

  Prompt :
  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].

3. Stratégies et techniques d'optimisation

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 collect par 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].

• Éliminer le travail inutile [08:46] :

  • • Technique : Comprendre les besoins stricts de l'application. En ignorant le parsing des adresses IP provenant des machines de développement ou de CI/CD, l'application réduit sa charge de travail [09:04].
  • Résultat : Le temps d'exécution descend à 250 ms (16 % d'amélioration supplémentaire) [09:22].

• Paralléliser le travail avec Rayon et DashMap [09:37] :

  • Technique : Utiliser la bibliothèque Rayon pour transformer les itérateurs séquentiels en itérateurs parallèles, et DashMap pour 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

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 %)