Oh, l'homme, par où commencer?
Tout d'abord, je suis étonné de voir que ce sont des nouvelles. Deuxièmement, le problème n'est pas que ceux-ci sont mauvais, c'est que certains des profileurs sont mauvais.
Les auteurs ont construit un qu'ils se sentent, est bonne, juste en évitant les erreurs qu'ils ont trouvé dans ceux qu'ils évalués.
Les erreurs sont fréquentes en raison de certains persistante des mythes 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 doit être corrélée avec l'état du programme.
Que signifie arrive à un véritablement aléatoire, peu importe si le programme est en I/O (à l'exception des entrées de l'utilisateur), ou dans le GC, ou dans un virage serré CPU boucle, ou quoi que ce soit.
L'échantillonnage doit lire la pile d'appel,
afin de déterminer lequel des états financiers ont été "actif" à l'époque de l'échantillon.
La raison en est que chaque site d'appel (à partir de laquelle une fonction est appelée) a un coût en pourcentage égal à la fraction de temps, il est sur la pile.
(Remarque: le papier est intéressé entièrement soi-même avec le temps, en ignorant l'impact massif de évitables appels de fonction dans les grands logiciels. En fait, la raison derrière l'original gprof était de l'aider à trouver ces appels.)
Les rapports montrent pour cent par ligne) (pas en fonction).
Si un "chaud" de la fonction est identifiée, on a encore à chasser à l'intérieur pour le "chaud" de lignes de code de la comptabilité pour le moment. Cette information est dans les échantillons! Pourquoi le cacher?
Quasi universel erreur (que le papier d'actions) est à être concerné aussi beaucoup avec l'exactitude de la mesure, et pas assez avec une précision de localisation.
Pour exemple, voici un exemple de réglage des performances
dans lequel une série de problèmes de performance ont été identifiés et résolus, résultant en un composé de l'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 fixer, mais pour connaître son emplacement.
Un phénomène de réglage des performances est que la fixation d'un problème, en réduisant le temps, multiplie les pourcentages de problèmes restants, de sorte qu'ils sont plus faciles à trouver.
Tant que tout problème est trouvé et corrigé, un progrès vers l'objectif de trouver et de corriger tous les problèmes.
Il n'est pas indispensable de les résoudre dans l'ordre décroissant, mais il est essentiel de les déterminer.
Sur le sujet de l'exactitude des statistiques de mesure, si un point est sur la pile d'un certain pourcentage de temps F (20%), et N (100) tirage au temps de la prise d'échantillons, le nombre d'échantillons qui montrent le point d'appel est une distribution binomiale, avec une moyenne de = NF = 20, écart-type = sqrt(NF(1-F)) = sqrt(16) = 4. Donc, le pourcentage d'échantillons qui montrent qu'elle sera de 20% +/- 4%.
Donc, est-ce exact? Pas vraiment, mais le problème a été trouvée? Précisément.
En fait, le plus gros problème est, en termes de pourcentage, le moins d'échantillons sont nécessaires pour le localiser. Par exemple, si 3 de la prise d'échantillons, et d'un point d'appel s'affiche sur 2 d'entre eux, il est très susceptible d'être très coûteux.
(Plus précisément, il s'en suit une distribution bêta. Si vous générez 4 uniforme de 0,1 nombres aléatoires, et de les trier, de la distribution de la 3e est la répartition des coûts pour que le point d'appel.
C'est-à-dire est (2+1)/(3+2) = 0.6, c'est ainsi que les économies attendues, compte tenu de ces échantillons.)
INSÉRÉ: Et l'accélération facteur que vous obtenez est régi par une autre distribution, BetaPrime, et sa moyenne est de 4. Donc, si vous prenez 3 échantillons, voir un problème sur 2 d'entre eux, et d'éliminer ce problème, en moyenne vous permettra de faire le programme de quatre fois plus rapide.
Il est grand temps de nous, programmeurs, a soufflé les toiles d'araignées de nos têtes sur le sujet du profilage.
Avertissement - le papier a omis de faire référence à mon article: Dunlavey, "optimisation des Performances avec le niveau d'instruction des coûts dérivés de la pile des appels d'échantillonnage", ACM SIGPLAN Notices 42, 8 (août 2007), pp. 4-8.
