{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Quel est l'avantage principal de BenchmarkDotNet par rapport à un simple Stopwatch pour mesurer les performances ?","acceptedAnswer":{"@type":"Answer","text":"BenchmarkDotNet effectue des warm-ups, mesure plusieurs itérations avec stabilisation statistique, évite les biais JIT et GC. Un Stopwatch simple peut donner des résultats non représentatifs car il ne contrôle pas ces facteurs. BenchmarkDotNet fournit également des métriques détaillées comme les allocations mémoire par opération."}},{"@type":"Question","name":"Quel outil Microsoft est recommandé pour analyser les allocations mémoire et identifier les fuites mémoire en production ?","acceptedAnswer":{"@type":"Answer","text":"dotMemory de JetBrains et PerfView de Microsoft sont les outils recommandés pour profiler la mémoire en .NET. PerfView est gratuit, open-source et peut analyser les allocations heap, les stacks traces et les événements GC. Il est particulièrement adapté pour diagnostiquer les fuites mémoire en production sans overhead significatif."}},{"@type":"Question","name":"Comment identifier les allocations mémoire cachées dans une méthode LINQ comme FirstOrDefault() ?","acceptedAnswer":{"@type":"Answer","text":"Utiliser BenchmarkDotNet avec l'attribut MemoryDiagnoser permet de voir les allocations par opération. Les lambdas LINQ créent des allocations cachées via delegates. Remplacer par une boucle foreach simple élimine ces allocations. PerfView peut aussi capturer les stacks traces d'allocations pour identifier les sources."}},{"@type":"Question","name":"Dans BenchmarkDotNet, quel attribut utiliser pour mesurer les performances CPU et identifier les hotspots de code ?","acceptedAnswer":{"@type":"Answer","text":"L'attribut DisassemblyDiagnoser permet de voir le code assembleur généré et identifier les optimisations JIT. Pour le profiling CPU, utiliser un profiler externe comme dotTrace ou PerfView en parallèle de BenchmarkDotNet. HardwareCounters peuvent aussi mesurer les instructions CPU, cache misses et branch mispredictions pour identifier les hotspots."}},{"@type":"Question","name":"Comment interpréter un résultat BenchmarkDotNet montrant Mean: 125.3 ns, StdDev: 45.2 ns ?","acceptedAnswer":{"@type":"Answer","text":"Un écart-type (StdDev) élevé de 45.2 ns sur une moyenne de 125.3 ns indique une variance importante (36%). Cela peut signaler un biais JIT, des GC non stabilisés ou des variations système. Il faut augmenter le nombre d'itérations, vérifier les warm-ups et potentiellement isoler le processus pour obtenir des résultats plus stables."}},{"@type":"Question","name":"Comment détecter une régression de performance dans une pipeline CI/CD avec BenchmarkDotNet ?","acceptedAnswer":{"@type":"Answer","text":"Exporter les résultats BenchmarkDotNet en JSON, les comparer avec les résultats baseline stockés et définir des seuils de régression acceptables (par exemple +10%). Des outils comme BenchmarkDotNet.ResultsComparer ou des scripts custom peuvent automatiser cette comparaison. Important d'exécuter sur du hardware dédié pour éviter les variations."}},{"@type":"Question","name":"Quel est l'impact performance du boxing d'un int en object dans une boucle de 1 million d'itérations ?","acceptedAnswer":{"@type":"Answer","text":"Chaque boxing crée une allocation heap (24 bytes sur x64). Pour 1 million d'itérations, cela représente 24 MB d'allocations générant une pression GC significative. Le boxing coûte aussi en cycles CPU pour l'allocation et la copie. Utiliser des types génériques évite complètement ce overhead en préservant les value types."}},{"@type":"Question","name":"Quel est l'avantage principal de Span par rapport à T[] pour les opérations temporaires sur des données ?","acceptedAnswer":{"@type":"Answer","text":"Span est un ref struct stack-allocated qui ne nécessite aucune allocation heap. Il permet de créer des vues sur des segments de mémoire existants sans copie. Pour des opérations temporaires, cela évite complètement les allocations et la pression GC. De plus, Span peut pointer vers stack memory (via stackalloc), unmanaged memory ou arrays existants."}},{"@type":"Question","name":"Dans quel scénario utiliser stackalloc au lieu d'un array classique ?","acceptedAnswer":{"@type":"Answer","text":"stackalloc alloue sur la stack, évitant les allocations heap et le GC. Idéal pour des buffers temporaires de petite taille (< 1 KB recommandé) utilisés dans une seule méthode. Au-delà de quelques KB, risque de stack overflow. Parfait pour des calculs cryptographiques temporaires, parsing de strings ou buffers réseau éphémères avec Span."}},{"@type":"Question","name":"Comment utiliser ArrayPool pour optimiser les allocations dans un serveur web haute performance ?","acceptedAnswer":{"@type":"Answer","text":"ArrayPool.Shared fournit un pool d'arrays réutilisables. Appeler Rent() pour obtenir un array, l'utiliser, puis Return() pour le rendre au pool. Cela évite des millions d'allocations dans un serveur gérant 10000+ requests/sec. Critiques : toujours Return() (utiliser using ou try/finally), clear les données sensibles avant Return(), accepter que l'array rendu puisse être plus grand que demandé."}},{"@type":"Question","name":"Quelle est la différence de performance entre ValueTask et Task pour une méthode souvent synchrone ?","acceptedAnswer":{"@type":"Answer","text":"ValueTask est un struct qui peut retourner un résultat synchrone sans allocation heap. Quand le résultat est disponible immédiatement (ex: cache hit 95% du temps), ValueTask évite l'allocation d'un Task. Pour des méthodes toujours asynchrones ou rarement appelées, Task reste préférable car ValueTask a des restrictions (pas de await multiple, pas de stockage dans des fields)."}},{"@type":"Question","name":"Comment optimiser les performances de StringBuilder quand la taille finale est approximativement connue ?","acceptedAnswer":{"@type":"Answer","text":"Spécifier une capacité initiale via le constructeur StringBuilder(capacity) évite les réallocations et copies multiples du buffer interne. Sans capacité, StringBuilder double sa taille à chaque dépassement (16 → 32 → 64...), causant des allocations et copies coûteuses. Si on construit un JSON de ~2KB, initialiser avec new StringBuilder(2048) améliore les performances de 30-50%."}},{"@type":"Question","name":"Quel est l'avantage de string interning pour des chaînes répétitives comme des constantes de configuration ?","acceptedAnswer":{"@type":"Answer","text":"String.Intern() stocke une seule instance de la chaîne dans le pool interne du CLR. Pour des chaînes répétées des milliers de fois (ex: \"ConnectionString\" dans un cache), cela réduit drastiquement l'utilisation mémoire. Les comparaisons deviennent aussi des comparaisons de références (très rapides). Attention : les strings internées ne sont jamais garbage collectées, donc à utiliser uniquement pour des strings à durée de vie longue."}},{"@type":"Question","name":"Comment Lazy améliore-t-il les performances lors de l'initialisation coûteuse d'objets rarement utilisés ?","acceptedAnswer":{"@type":"Answer","text":"Lazy diffère l'initialisation jusqu'au premier accès à la propriété Value. Si l'objet n'est jamais utilisé (ex: fallback service 1% du temps), l'initialisation coûteuse ne se produit jamais. Pour un service nécessitant 200ms d'initialisation mais utilisé seulement 5% du temps, cela évite 95% du temps de démarrage. Lazy est aussi thread-safe par défaut."}},{"@type":"Question","name":"Quel est l'impact des générations du GC (Gen0, Gen1, Gen2) sur les performances d'une application web ?","acceptedAnswer":{"@type":"Answer","text":"Gen0 contient les objets court-terme et est collecté fréquemment (< 1ms). Gen1 est un buffer intermédiaire. Gen2 contient les objets long-terme et sa collection est coûteuse (10-100ms), bloquant tous les threads. Dans une web app, trop d'objets promus en Gen2 causent des pauses perceptibles. Objectif : la plupart des objets meurent en Gen0. Minimiser les allocations et utiliser object pooling réduit la pression GC."}},{"@type":"Question","name":"Comment optimiser les allocations pour éviter le Large Object Heap (LOH) et ses problèmes de fragmentation ?","acceptedAnswer":{"@type":"Answer","text":"Le LOH stocke les objets ≥ 85KB et n'est jamais compacté par défaut, causant de la fragmentation. Stratégies : utiliser ArrayPool pour réutiliser les gros buffers, segmenter les données en morceaux < 85KB, activer LOH compaction explicitement avec GCSettings.LargeObjectHeapCompactionMode (mais coûteux). Pour un buffer de 1MB fréquent, ArrayPool évite complètement le LOH."}},{"@type":"Question","name":"Quel est l'impact performance d'un finalizer (destructeur ~ClassName) sur un objet fréquemment alloué ?","acceptedAnswer":{"@type":"Answer","text":"Les finalizers forcent l'objet à survivre une collection GC supplémentaire (promotion vers génération supérieure). L'objet n'est libéré qu'après passage dans la queue de finalisation. Pour des objets fréquents (10000/sec), cela augmente drastiquement la pression GC et les promotions vers Gen2. Préférer IDisposable avec pattern Dispose et éviter les finalizers sauf absolument nécessaire (ressources unmanaged)."}},{"@type":"Question","name":"Comment implémenter correctement IDisposable pour garantir la libération rapide des ressources tout en évitant les fuites ?","acceptedAnswer":{"@type":"Answer","text":"Implémenter le pattern Dispose standard : méthode Dispose() publique qui appelle Dispose(bool disposing), supprime le finalizer avec GC.SuppressFinalize(this), et libère les ressources managées si disposing=true et unmanaged toujours. Utiliser using ou using declaration pour garantir l'appel. Ne jamais jeter d'exceptions dans Dispose(). Rendre la méthode idempotente (peut être appelée plusieurs fois)."}},{"@type":"Question","name":"Quel est le principal problème de performance avec LINQ FirstOrDefault() utilisant une lambda sur une liste de 100000 éléments ?","acceptedAnswer":{"@type":"Answer","text":"FirstOrDefault avec lambda crée une allocation heap pour le delegate (closure) à chaque appel. Sur 100000 éléments parcourus fréquemment, cela génère des millions d'allocations. Remplacer par une simple boucle foreach élimine ces allocations. L'allocation du delegate est souvent invisible mais mesurable avec BenchmarkDotNet MemoryDiagnoser. Gain typique : 40-60% de réduction des allocations."}},{"@type":"Question","name":"Quelle est la meilleure pratique async/await pour éviter les deadlocks dans une bibliothèque réutilisable ?","acceptedAnswer":{"@type":"Answer","text":"Toujours utiliser ConfigureAwait(false) dans les bibliothèques pour éviter de capturer le SynchronizationContext. Sans cela, le code peut deadlock dans des applications UI (WPF, WinForms) ou ASP.NET Framework. ConfigureAwait(false) permet à la continuation de s'exécuter sur n'importe quel thread du ThreadPool. Dans ASP.NET Core, moins critique mais reste une bonne pratique pour les performances (évite le context switch)."}},{"@type":"Question","name":"Quel est l'ordre de performance (du plus rapide au plus lent) pour itérer 1 million d'éléments : Span, Array T[], List ?","acceptedAnswer":{"@type":"Answer","text":"Span est le plus rapide car il permet des optimisations JIT agressives (bounds check elimination, vectorisation SIMD). Array T[] est très proche mais avec bounds checking léger. List est le plus lent car il ajoute une indirection (accès via field interne _items) et des vérifications de version. Différence typique : Span 100%, Array 102%, List 115% du temps. Pour hot paths, préférer Span ou Array."}},{"@type":"Question","name":"Dans quel scénario privilégier un struct au lieu d'une class pour optimiser les performances mémoire ?","acceptedAnswer":{"@type":"Answer","text":"Privilégier struct pour des types petits (< 16 bytes recommandé), immuables et fréquemment copiés (ex: Point, Vector2, DateTime). Les structs évitent les allocations heap et le GC mais sont copiés par valeur. Pour des collections de 1 million de Point structs vs classes, économie de ~32 MB de heap et élimination de la pression GC. Éviter structs pour types > 16 bytes (coût de copie) ou mutables (confusion sémantique)."}}]}