Si profiler n’est pas la solution, quels autres choix avons-nous?

Après avoir regardé la présentation “Performance Anxiety” de Joshua Bloch, j’ai lu l’article qu’il avait suggéré dans la présentation “Evaluer la précision des fi ltres Java” . Citant la conclusion:

Nos résultats sont inquiétants car ils indiquent que les erreurs de pro fi ls sont omniprésentes – se produisant dans la plupart de nos sept références et dans deux JVM de production – et signi fi catives – les quatre pro- ducteurs de pointe produisent des profils incorrects. Des profils incorrects peuvent facilement amener un analyste de la performance à consacrer du temps à l’optimisation des méthodes froides qui auront un impact minimal sur les performances. Nous montrons qu’un pro fi l de validation qui n’utilise pas de points de rendement pour l’échantillonnage ne souffre pas des problèmes ci-dessus.

La conclusion de l’article est que nous ne pouvons pas vraiment croire le résultat des profileurs. Mais alors, quelle est l’alternative d’utiliser des profileurs. Devrions-nous revenir en arrière et simplement utiliser notre sentiment pour faire de l’optimisation?

MISE À JOUR : Un point qui semble manquer dans la discussion est l’ effet d’observateur . Pouvons-nous construire un profileur sans effets d’observateur ?

Oh, mec, par où commencer?

D’abord, je suis étonné que ce soit des nouvelles. Deuxièmement, le problème n’est pas que les profileurs sont mauvais, mais que certains profileurs sont mauvais. Les auteurs en ont construit un qui, à leur avis, est bon, simplement en évitant certaines des erreurs qu’ils ont trouvées dans celles qu’ils ont évaluées. Les erreurs sont fréquentes en raison de certains mythes persistants sur le profilage des performances .

Mais soyons positifs. Si l’on veut trouver des opportunités d’accélération, c’est vraiment très simple:

  • L’échantillonnage devrait être décorrélé de l’état du programme.
    Cela signifie qu’il se produit à un moment vraiment aléatoire, que le programme soit en E / S (sauf pour les entrées utilisateur), ou en GC, ou dans une boucle de processeur étroite, etc.

  • L’échantillonnage devrait lire la stack d’appels de fonction ,
    afin de déterminer quelles déclarations étaient “actives” au moment de l’échantillon. La raison en est que chaque site d’appel (point auquel une fonction est appelée) a un pourcentage de coût égal à la fraction de temps qu’il occupe sur la stack. (Remarque: le papier concerne uniquement le self-time, en ignorant l’impact massif des appels de fonctions évitables dans les gros logiciels. En fait, la raison derrière le gprof original était d’aider à trouver ces appels.)

  • Le rapport doit indiquer le pourcentage par ligne (et non par fonction).
    Si une fonction “chaude” est identifiée, il faut toujours y chercher les lignes de code “chaudes” pour le temps. Cette information est dans les échantillons ! Pourquoi le cacher?

Une erreur presque universelle (que les actions papier) consiste à trop se préoccuper de la précision de la mesure , et pas assez de la précision de la localisation . Par exemple, voici un exemple de réglage des performances dans lequel une série de problèmes de performances ont été identifiés et corrigés, ce qui a entraîné une accélération de 43 fois. Il n’était pas indispensable de connaître précisément la taille de chaque problème avant de le corriger, mais de connaître son emplacement. Un phénomène d’optimisation des performances est que la résolution d’un problème, en réduisant le temps, amplifie les pourcentages de problèmes restants, ce qui facilite leur recherche. Tant que tout problème est trouvé et corrigé, des progrès sont réalisés dans le but de trouver et de résoudre tous les problèmes. Il n’est pas indispensable de les fixer dans un ordre décroissant de taille, mais il est essentiel de les identifier.

En ce qui concerne la précision statistique de la mesure, si un point d’appel est sur la stack, un pourcentage du temps F (comme 20%) et N (comme 100) échantillons aléatoires sont pris, puis le nombre d’échantillons qui montrent l’appel le point est une dissortingbution binomiale, avec une moyenne = NF = 20, écart-type = sqrt (NF (1-F)) = sqrt (16) = 4. Donc, le pourcentage d’échantillons qui le montrent sera de 20% +/- 4% . Est-ce exact? Pas vraiment, mais le problème a-t-il été trouvé? Précisément.

En fait, plus le problème est grand, plus le pourcentage d’échantillons requirejs pour le localiser est faible. Par exemple, si 3 échantillons sont pris et qu’un point d’appel apparaît sur 2 d’entre eux, il est très probable qu’il soit très coûteux. (Spécifiquement, il suit une dissortingbution bêta. Si vous générez 4 nombres aléatoires 0,1 uniformes, et sortingez-les, la dissortingbution du 3ème est la dissortingbution du coût pour ce point d’appel. Sa moyenne est (2 + 1) / ( 3 + 2) = 0,6, donc c’est les économies attendues, compte tenu de ces échantillons.) INSERTED: Et le facteur d’accélération que vous obtenez est régi par une autre dissortingbution, BetaPrime , et sa moyenne est 4. Donc, si vous prenez 3 échantillons, voyez un problème sur 2 d’entre eux, et éliminer ce problème, en moyenne, vous rendrez le programme quatre fois plus vite.

Il est grand temps que nous, les programmeurs, fassions sauter les canvass d’araignées au sujet du profilage.

Déni de responsabilité – l’article n’a pas référencé mon article: Dunlavey, «Optimisation des performances avec le coût au niveau de l’instruction dérivé de l’échantillonnage par stack d’appels», ACM SIGPLAN Notices 42, 8 (août 2007), pp. 4-8.

Si je le lis correctement, le document ne parle que du profilage basé sur des échantillons . De nombreux profileurs effectuent également un profilage basé sur l’instrumentation. C’est beaucoup plus lent et a d’autres problèmes, mais il ne devrait pas souffrir des préjugés dont parle le document.

La conclusion de l’article est que nous ne pouvons pas vraiment croire le résultat des profileurs. Mais alors, quelle est l’alternative d’utiliser des profileurs.

Non. La conclusion de l’article est que les méthodes de mesure actuelles des profileurs présentent des défauts spécifiques. Ils proposent un correctif. Le papier est assez récent. Je m’attendrais à ce que les profileurs implémentent ce correctif à terme. Jusque-là, même un profileur défectueux est encore bien meilleur que “sentir”.

À moins que vous ne développiez des applications à la pointe de la technologie qui nécessitent chaque cycle de processeur, j’ai constaté que les profileurs sont un bon moyen de trouver les parties les plus lentes de votre code. En tant que développeur, je dirais que cela devrait vous intéresser dans presque tous les cas.

J’ai de l’expérience avec http://www.dynatrace.com/en/ et je peux vous dire que c’est très bien pour trouver les fruits à scope de main.

Les profileurs sont comme n’importe quel autre outil et ils ont leurs bizarreries, mais je leur ferais confiance chaque jour pour trouver les points chauds de votre application à regarder.

Si vous ne faites pas confiance aux profileurs, vous pouvez passer en mode paranoïa en utilisant une programmation orientée aspect, en encapsulant chaque méthode de votre application, puis en utilisant un enregistreur pour consigner chaque invocation de méthode.

Votre application va vraiment ralentir, mais au moins vous aurez un compte précis du nombre de fois où chaque méthode est appelée. Si vous voulez aussi voir combien de temps chaque méthode prend pour exécuter, enroulez chaque méthode perf4j .

Après avoir transféré toutes ces statistiques dans des fichiers texte, utilisez certains outils pour extraire toutes les informations nécessaires, puis visualisez-les. Je suppose que cela vous donnera un bon aperçu de la lenteur de votre application à certains endroits.

En fait, il vaut mieux faire du profilage au niveau de la firebase database. La plupart des bases de données d’entreprise permettent d’afficher les requêtes les plus fréquentes sur une période donnée. Commencez à travailler sur ces requêtes jusqu’à ce que les plus hautes soient à 300 ms ou moins, et vous aurez accompli de grands progrès. Les profileurs sont utiles pour montrer le comportement du tas et pour identifier les threads bloqués, mais personnellement, je n’ai jamais eu beaucoup de contact avec les équipes de développement pour identifier les méthodes à chaud ou les gros objects.