Les vues du graphique d'appel de performance et Détails de méthode vous permettent d'identifier les parties de application demandant le plus de temps. Vous pouvez alors étudier comment rendre plus efficaces ces parties gourmandes en temps. Lorsque vous analysez le code de votre application, il est utile de connaître les erreurs de codage les plus fréquentes entraînant une performance médiocre.
Calcul nécessaire : à mesure que les applications évoluent et que les algorithmes sont détaillés, ou à mesure que les données changent, des parties du code nécessaires dans des versions antérieures peuvent devenir inutiles, sans devoir pour autant être supprimées. C'est la raison pour laquelle nombre de programmes importants exécutent des calculs dont les résultats ne sont jamais utilisés. Des goulots d'étranglement résultent du temps perdu sur ce code inutile.
D'autres calculs inutiles habituels sont ceux réalisés automatiquement ou par défaut, même s'ils ne sont pas nécessaires. Des applications qui libèrent inutilement des structures de données pendant l'arrêt d'un programme ou qui ouvrent des connexions avec des postes de travail même si aucun utilisateur n'est présent sont des exemples de ce type de goulot d'étranglement. Vous pouvez profiler la performance afin de connaître le temps passé sur le code inutile. Lorsque vous serez sûr que les résultats d'un calcul sont inutiles, vous pourrez supprimer le code.
Calcul anticipé : tout calcul réalisé avant que ses résultats ne soient nécessaires peut entraîner un goulot d'étranglement. Par exemple, le tri d'une liste de chiffres peut être inutile si l'utilisateur n'a pas demandé un tel tri. Les données de performance ne peuvent pas vous indiquer si tel calcul peut être différé. Cependant, elles peuvent vous indiquer le coût du calcul ; à vous de choisir alors s'il peut être différé ou non.
Recalcul inutile : les programmes recalculent parfois des valeurs utiles plutôt que de les mettre en cache pour une utilisation ultérieure. Par exemple, la détermination de la longueur d'une chaîne constante peut entraîner un calcul inutile si le calcul est intégré à une boucle. La longueur de la chaîne est recalculée plusieurs fois, et donne chaque fois la même valeur. Vos données de performance peuvent vous informer quand le recalcul se produit, et vous pouvez choisir de stocker la valeur après un calcul.
Calcul inefficace : un choix médiocre de présentation de l'algorithme ou de la structure de données peut entraîner un travail supplémentaire pour le programme. La performance initiale peut paraître acceptable, étant donné le faible jeu de données, mais devient de plus en plus médiocre à mesure que les jeux de données augmentent ou deviennent plus complexes. Le profilage de la performance peut vous indiquer le coût de chaque calcul à différentes échelles afin que vous puissiez prévoir si un incident peut se produire avec des jeux de données encore plus importants. Vous pouvez alors utiliser d'autres algorithmes et structures de données permettant d'accélérer le travail.
Les fuites de mémoire et les goulots d'étranglement au niveau unité d'exécution peuvent également dégrader la performance. Utilisez les jeux de profilages Détection de fuite et Analyse d'unité d'exécution pour collecter des données afin de résoudre ces incidents. Notez que vous ne pouvez pas collecter de données de détection de fuite alors que vous collecter simultanément d'autres données d'analyse en contexte d'exécution.