Écrire du code .Net performant : profilage, benchmarking et bonnes pratiques

Auteur(s) :

Mommer, Christophe Découvrir l'auteur

Résumé

Des méthodes simples pour profiler une application et retrouver rapidement les 20 % d'erreurs de code qui correspondent à 80 % du ralentissement. Après avoir montré comment détecter les erreurs dans les résultats d'un outil profileur .Net, les auteurs livrent des astuces pour résoudre les problèmes. Avec des quiz et la version en ligne de l'ouvrage.

Éditeur(s)
- Éditions ENI
Date
- C 2022
Notes
- La couv. porte en plus : "Jean-Philippe Gouigoux" ; "En téléchargement : applications en C#, benchmarks de codes .NET" ; "Informatique technique" ; "+quiz", "Version offerte ! pendant un an"
- La 4e de couv. porte en plus : "sur www.editions-eni.fr : application de démonstration en C#, benchmarks de performances de codes .NET"
- Contient un "flashcode" permettant d'accéder à un contenu via Internet
Langues
- Français
Description matérielle
- 1 vol. (326 p.) : ill. ; 21 cm
Collections
- Expert IT
Sujet(s)
ISBN
- 978-2-409-03613-2
Indice
- 681.22 Langages, environnements de développement
Quatrième de couverture
- Écrire du code .NET performant
  Profilage, benchmarking et bonnes pratiques
  Ce livre sur la performance du code .NET s'adresse aux développeurs débutants comme expérimentés qui ont à faire face à des problèmes de performances sur leurs développements.
  Dans ce livre, les auteurs se consacrent à démystifier la performance du code .NET: il ne vous entraînera pas sur les pentes ardues du tuning, mais vous donnera des méthodes simples pour profiler une application et retrouver rapidement les 20 % d'erreurs de code qui correspondent à 80% du ralentissement. Il vous donnera tous les outils théoriques nécessaires pour savoir précisément où chercher les problèmes de performance et comment les corriger.
  Après avoir exposé la méthode et les outils, les auteurs s'appuient sur une application de démonstration (écrite en C#) pour vous faire découvrir les méthodes de recherche des goulets d'étranglement. Cette application a été spécialement conçue pour contenir un grand éventail des erreurs de code traditionnellement à l'origine de problèmes de performances. Le livre vous montrera comment détecter ces différentes erreurs dans les résultats d'un outil « profiteur .NET », puis tes analyser finement et enfin tes corriger. L'application correspond aux architectures web modernes, avec un client (en Blazor WebAssembly) et une API (en ASP.NET 6). À l'aide de Visual Studio 2022, la toute dernière version de l'IDE, le lecteur découvrira comment l'outil peut remonter tes métriques permettant de trouver tes problèmes rapidement.
  Des éléments complémentaires sont en téléchargement sur www.editions-eni.fr
  Sur www.editions-eni.fr :
  
  application de démonstration en C#.
  
  benchmarks de performances de codes .NET.
Tables des matières
- - Écrire du code .NET performant
  - Profilage, benchmarking et bonnes pratiques
  - Éditions ENI
  - Chapitre 1
  - Introduction
  - 1. Avant-propos9
  - 2. Les risques de la suroptimisation10
  - 3. Le principe du profilage et du benchmarking12
  - 4. L'enjeu financier et écologique15
  - 5. Méthodologie17
  - 6. Environnement nécessaire18
  - Chapitre 2
  - Principes du profilage
  - 1. Une activité strictement régulée19
  - 2. Stabilité de la plate-forme26
  - 2.1 Pourquoi cette règle ?26
  - 2.2 Comment appliquer cette règle ?26
  - 2.3 Extraire les cas particuliers27
  - 2.4 Lien avec la maintenabilité29
  - 3. Neutralité de l'environnement31
  - 3.1 Le principe31
  - 3.2 Virtualisation32
  - 3.2.1 Virtualisation lourde32
  - 3.2.2 Virtualisation légère33
  - 3.3 Déport d'affichage34
  - 3.4 Effets de caches externes35
  - 3.5 Processus externe36
  - 3.6 Services divers37
  - 3.7 Comparaison avec la nano-technologie38
  - 4. Objectifs fixés avant l'analyse39
  - 5. Améliorations mesurables42
  - 5.1 Pourquoi cette règle ?42
  - 5.2 Comment appliquer cette règle ?42
  - 6. Granularité descendante44
  - 6.1 Commençons par une parabole44
  - 6.2 Un exemple44
  - 6.3 Avertissement45
  - 6.4 Qui est responsable ?47
  - Chapitre 3
  - Profilage d'une application .NET
  - 1. Gestion de la mémoire par .NET49
  - 1.1 Principes de base49
  - 1.2 Gestion de mémoire automatisée et performances50
  - 1.3 Le cas particulier du temps réel50
  - 1.3.1 Lever un malentendu50
  - 1.3.2 Non-déterminisme des ramasse-miettes52
  - 1.4 Affectation de la mémoire55
  - 1.5 Comment .NET nous aide61
  - 1.6 Types valeurs et références62
  - 1.6.1 Fonctionnement d'une pile63
  - 1.6.2 Retour sur le code IL69
  - 1.6.3 Différence entre valeur et référence71
  - 1.6.4 Cas particulier des structures76
  - 1.6.5 Lien à la performance78
  - 1.7 Calcul de la taille mémoire à affecter79
  - 1.7.1 Cas du code 100 % géré79
  - 1.7.2 Cas des objets sujets à interopérabilité80
  - 1.8 Collecte de la mémoire82
  - 1.8.1 Critères de collecte de la mémoire82
  - 1.8.2 Mécanisme de compactage84
  - 1.8.3 Mémoire fixée et fragmentation85
  - 1.8.4 Déclenchement et exécution du ramasse-miettes87
  - 1.8.5 Notion de génération88
  - 1.8.6 Impact sur le codage pour la performance90
  - 1.8.7 Choix du ramasse-miettes93
  - 1.9 Boxing, unboxing et performances associées95
  - 1.9.1 Quel est le problème ?95
  - 1.9.2 Le boxing/unboxing et les performances100
  - 1.9.3 Le remède102
  - 1.10 Gestion de mémoire et finalisation106
  - 1.10.1 Laissons faire .NET !106
  - 1.10.2 Relâcher des ressources externes lors du passage du GC107
  - 1.10.3 Fonctionnement du finaliseur110
  - 1.10.4 Relâcher les ressources au plus tôt112
  - 1.10.5Combiner les deux opérations115
  - 1.11 Une dernière remarque119
  - 2. Particularité des fonctions inline120
  - 2.1 Mécanisme des fonctions inline120
  - 2.2 Problématiques de performance et fonctions inline125
  - 2.3 Impact sur les profileurs129
  - 3. Impact de la gestion mémoire sur la performance132
  - 3.1 Une grande diversité dans les impacts132
  - 3.2 Utilisation de la mémoire virtuelle133
  - 3.3 Fuites mémoire137
  - 3.4 Tas spécial pour les gros objets et fragmentation mémoire143
  - 4. Les autres ressources à surveiller146
  - 4.1 La mémoire n'est pas tout146
  - 4.2 Le CPU146
  - 4.3 Les entrées/sorties150
  - 4.4 L'espace disque disponible152
  - 4.5 La bande passante153
  - Chapitre 4
  - Application de test
  - 1. Préambule155
  - 1.1 Une migration historique155
  - 2. Critères de choix156
  - 2.1 Pourquoi cette application ?156
  - 2.2 Utiliser des retours d'expérience157
  - 2.3 Le choix de la transparence158
  - 2.4 Les limites de la transparence159
  - 3. Application choisie160
  - 3.1 Domaine d'utilisation160
  - 3.2 Architecture160
  - 3.3 Interface161
  - 3.4 Description du métier161
  - 4. Détail de l'application162
  - 4.1 Trouver l'application162
  - 4.2 Installation de la base de données162
  - 4.2.1 Création manuelle163
  - 4.2.2 Utilisation des scripts de génération164
  - 4.3 Installation de l'application165
  - 4.3.1 Ouverture de la solution165
  - 4.3.2 Configuration des projets165
  - 4.3.3 Exécution de l'application166
  - 4.4 Détails des assemblages167
  - 4.5 Architecture du client168
  - 4.6 Structure des services web168
  - 4.7 Structure de la base de données169
  - 5. Explication de la lourdeur de l'application169
  - 6. Méthode recommandée170
  - Chapitre 5
  - Présentation des outils
  - 1. Choix des outils173
  - 2. Visual Studio 2022174
  - 2.1 Fenêtre de diagnostic175
  - 2.2 Session de profilage177
  - 3. Compteurs de performance181
  - 3.1 Terminologique181
  - 3.2 Windows182
  - 3.3 Linux et macOS186
  - 4. BenchmarkdotNet188
  - 4.1 Création du projet de benchmark189
  - 4.2 Création d'un benchmark189
  - 4.3 Exécuter le benchmark191
  - 5. Outils alternatifs192
  - Chapitre 6
  - Profilage
  - 1. Par où commencer ?193
  - 2. Scénarios de profilage194
  - 2.1 Premier scénario : afficher le détail d'une personne194
  - 2.2 Deuxième scénario : afficher et éditer un contrat197
  - 3. Lancement du profilage198
  - 3.1 Profilage de l'API : premier scénario199
  - 3.1.1 Exécution avec profiler201
  - 3.1.2 Première optimisation206
  - 3.1.3 Test de charge209
  - 3.1.4 Seconde optimisation215
  - 3.2 Refactoring suite aux optimisations218
  - 3.2.1 Mélange des responsabilités219
  - 3.2.2 Suppression du static220
  - 3.2.3 Utilisation de l'injection de dépendances221
  - 3.2.4 Profilage de l'API : premier scénario, après refactoring227
  - 3.3 Profilage de l'API : deuxième scénario229
  - 3.3.1 Analyse de la consommation mémoire229
  - 3.3.2 Première optimisation235
  - 3.3.3 Benchmark du dézippage du fichier contrat239
  - 3.3.4 Seconde optimisation242
  - 3.3.5 Mise en place du pooling246
  - 4. Conclusion250
  - Chapitre 7
  - Au-delà du profilage
  - 1. Introduction253
  - 2. Pistes d'amélioration restantes254
  - 2.1 Introduction254
  - 2.2 Amélioration du ressenti255
  - 2.3 Temps de chargement de l'application259
  - 2.4 Asynchronisme des traitements266
  - 2.5 Marquer les changements d'application269
  - 2.6 Quelques dernières problématiques269
  - 2.6.1 Gestion correcte des traces270
  - 2.6.2 Duplication des requêtes SQL270
  - 2.6.3 Éviter la sur-architecture272
  - 2.6.4 Pagination des résultats273
  - 2.6.5 Le ramasse-miettes prend du temps274
  - 2.6.6 Limiter les exceptions275
  - 2.6.7 Fonctions Equals et GetHashCode276
  - 2.6.8 AddRange277
  - 2.6.9 Concaténation de chaînes279
  - 3. Tuning282
  - 3.1 Caveat282
  - 3.2 Compiler en release283
  - 3.3 Le curseur de la consistance284
  - 3.3.1 BASE au lieu d'ACID284
  - 3.3.2 Un second exemple286
  - 3.3.3 Passer le code de PROFI en BASE287
  - 3.4 Asynchronisme globalisé292
  - 3.5 Utiliser des références faibles293
  - 3.6 Attention au tuning extrême294
  - 3.6.1 Limites du tuning294
  - 3.6.2 Struct au lieu de class294
  - 3.6.3 Instanciation tardive et déréférencement précoce296
  - 3.6.4 Byte au lieu de int dans Enum ?297
  - 4. Aller plus loin en réarchitecturant298
  - 4.1 Problématique298
  - 4.2 Scalabilité299
  - 4.2.1 Concept299
  - 4.2.2 Modes de scalabilité299
  - 4.2.3 Parallélisation des traitements300
  - 4.2.4 Bonnes pratiques pour la scalabilité301
  - 4.2.5 Parallel Linq301
  - 4.3 Institutionnaliser le cache304
  - 4.4 Penser Lean/Agile304
  - 4.4.1 IMDB304
  - 4.4.2 NoSQL304
  - 4.4.3 CQRS305
  - 4.4.4 Prévalence305
  - 4.5 Performance des nouvelles architectures306
  - 4.5.1 Problématique306
  - 4.5.2 Scale Out307
  - 4.5.3 Parallélisation307
  - 4.5.4 Mobilité307
  - 4.5.5 SOA/EDA/ESB308
  - 4.6 Et pour aller encore plus loin310
  - Conclusion
  - 1. Tout peut poser problème311
  - 2. Checklist312
  - 3. Les causes des erreurs314
  - 4. Coder léger316
  - 5. Conclusion317
  - Index319
Origine de la notice:
- BPI