On pourrait utiliser un profileur, mais pourquoi ne pas simplement arrêter le programme?

Question

Si quelque chose est de faire un thread unique programme de prendre, disons, 10 fois plus longtemps qu'il le devrait, vous pourriez exécuter un profiler sur elle. Vous pourriez tout aussi bien arrêter avec un bouton "pause", et vous verrez exactement ce qu'il fait.

Même si c'est seulement 10% plus lent que ce qu'elle devrait être, si vous arrêter plusieurs fois, avant longtemps, vous allez le voir à plusieurs reprises de faire la chose inutile. Habituellement, le problème est un appel de fonction quelque part dans le milieu de la pile qui n'est pas vraiment nécessaire. Cela ne permet pas de mesurer l'ampleur du problème, mais c'est sûr qu'il ne le trouver.

Edit: Les objections pour la plupart supposent que vous prenez seulement à 1 échantillon. Si vous êtes sérieux, de prendre 10. Aucune ligne de code à l'origine de certains pourcentage de pertes, à l'instar de 40%, apparaîtra sur la pile sur la fraction des échantillons, en moyenne. Les goulots d'étranglement (en mono-thread code) ne peut pas le cacher.

EDIT: Pour montrer ce que je veux dire, de nombreuses objections sont de la forme "il n'y a pas assez d'échantillons, de sorte que ce que vous voyez peut être fallacieuse" - vague idée sur le hasard. Mais si quelque chose de tout reconnaissable description, pas seulement d'être dans une routine ou l'habitude d'être actif, est en effet de 30% du temps, alors la probabilité de le voir sur tout l'échantillon est de 30%.

Ensuite, supposons que seulement 10 échantillons sont prélevés. Le nombre de fois que le problème sera vu dans 10 échantillons suit une distribution binomiale, et la probabilité de le voir 0 fois est .028. La probabilité de le voir 1 temps est .121. Pour les 2 fois, la probabilité est .233, et pour 3 fois c'est .267, après quoi il tombe. Puisque la probabilité de le voir moins deux fois est .028 + .121 = .139, cela signifie que la probabilité de le voir deux fois ou plus est de 1 - .139 = .861. La règle générale est que si vous voyez quelque chose que vous pourriez corriger sur deux échantillons ou plus, il vaut la peine de fixation.

Dans ce cas, les chances de le voir dans 10 échantillons est de 86%. Si vous êtes dans les 14% qui ne le voient pas, il suffit de prendre plusieurs échantillons jusqu'à ce que vous faites. (Si le nombre d'échantillons est porté à 20, la chance de le voir deux fois ou plus augmente de plus de 99%.) Donc, il n'a pas été mesurée avec précision, mais il a justement été trouvé, et il est important de comprendre qu'il pourrait facilement être quelque chose d'un profileur ne pouvait pas trouver, comme quelque chose impliquant l'état des données, pas le compteur de programme.

Answer 1

Sur les serveurs Java, c’était toujours une bonne astuce de faire 2-3 Ctrl - Casse - s de suite et d’obtenir 2-3 threaddumps de tous les threads en cours d’exécution. Le simple fait de regarder où se trouvent tous les "fils" peut permettre de localiser très rapidement vos problèmes de performances.

Cette technique peut révéler plus de problèmes de performances en 2 minutes que toute autre technique que je connaisse.

Answer 2

Parce que parfois cela fonctionne, et parfois cela vous donne des réponses complètement fausses. Un profileur a beaucoup mieux réussi à trouver la bonne réponse, et il y parvient généralement plus rapidement.

Answer 3

Faire cela manuellement ne peut pas vraiment s'appeler "rapide" ou "efficace", mais il existe plusieurs outils de profilage qui le font automatiquement; également connu sous le nom de profilage statistique .

Answer 4

Pile des appels d'échantillonnage est une technique très utile à des fins de profilage, surtout quand on regarde un grand complexe de la base de code qui pourrait passer son temps dans un certain nombre de lieux. Il a l'avantage de mesurer le PROCESSEUR par l'horloge murale, qui est tout ce qui compte pour l'interactivité, et d'obtenir des piles d'appels avec chaque échantillon vous permet de voir pourquoi une fonction est appelée. Je l'utilise beaucoup, mais je utiliser des outils automatisés pour elle, comme Luc Stackwalker et OProfile et divers matériel fourni par le fournisseur de choses.

La raison pour laquelle je préfère les outils automatisés sur l'échantillonnage manuel pour le travail que je fais est la puissance statistique. L'accaparement des dix échantillons à la main est très bien quand vous avez une fonction prenant en hausse de 40% de l'exécution, car en moyenne, vous obtiendrez quatre échantillons en elle, et toujours au moins un. Mais vous avez besoin de plus d'échantillons lorsque vous avez un profil plat, avec des centaines de feuilles de fonctions, aucune prise de plus de 1,5% de l'exécution.

Disons que vous avez un lac avec de nombreuses différentes sortes de poissons. Si 40% des poissons dans le lac sont le saumon (et 60% "tout le reste"), alors vous avez seulement besoin d'attraper dix poissons à savoir qu'il y a beaucoup de saumon dans le lac. Mais si vous avez des centaines de différentes espèces de poissons, et chaque espèce est individuellement pas plus de 1%, vous aurez besoin de prendre un lot de plus de dix poissons pour être en mesure de dire "ce lac est de 0,8% de saumon et de 0,6% de la truite."

De même, dans les jeux je travaille, il y a plusieurs grands systèmes de chacune d'appel des dizaines de fonctions dans des centaines de différentes entités, et tout cela se passe de 60 fois par seconde. Certaines de ces fonctions " temps des entonnoirs dans les opérations les plus courantes (comme malloc), mais la plupart ne le sont pas, et en tout cas il n'y a pas une seule feuille qui occupe plus de 1000 µs par image.

Je peux regarder le tronc de fonctions et de voir, "nous sommes dépenses de 10% de notre temps sur la collision", mais ce n'est pas très utile: j'ai besoin de savoir exactement où en collision, donc je sais qui sert à presser. Juste "faire moins collision" ne mène pas loin, surtout quand il signifie jeter des fonctionnalités. Je préfère savoir "nous dépensons une moyenne de 600 µs/image sur le cache dans les ruelles de la phase de l'octree , car la magie de missiles se déplace si vite et il touche beaucoup de cellules," parce que je peux traquer l'exacte correctif: une meilleure arbre, ou plus lentement, de missiles.

Manuel d'échantillonnage serait bien si il y avait un gros 20% lump dans, disons, stricmp, mais avec nos profils qui n'est pas le cas. Au lieu de cela j'ai des centaines de fonctions dont j'ai besoin pour obtenir à partir de, disons, de 0,6% de cadre à 0,4% du cadre. J'ai besoin de me raser, de 10 µs arrêt tous les 50 µs fonction qui est appelée à 300 fois par seconde. Pour obtenir ce genre de précision, j'ai besoin de plus d'échantillons.

Mais au cœur de ce que Luc Stackwalker n'est ce que vous décrivez: chaque milliseconde ou alors, il arrête le programme et les registres de la pile des appels (y compris le précise l'instruction et le numéro de ligne de la propriété intellectuelle). Certains programmes juste besoin de dizaines de milliers d'échantillons à être utilement présentées.

(Nous en avons parlé avant, bien sûr, mais j'ai pensé que c'était un bon endroit pour résumer le débat.)

Answer 5

Il y a une différence entre les choses que les programmeurs réellement faire, et des choses qu'ils recommandent à d'autres.

Je connais beaucoup de programmeurs (moi y compris) que le fait d'utiliser cette méthode. Il ne les aide vraiment à trouver la plus évidente des problèmes de performance, mais il est rapide et sale et ça fonctionne.

Mais je ne serais pas vraiment dire à d'autres programmeurs de le faire, car cela me prendrait trop de temps à expliquer toutes les mises en garde. Il est beaucoup trop facile de faire une fausse conclusion sur la base de cette méthode, et il ya de nombreux domaines où il n'a tout simplement pas de travail du tout. (pour exemple, cette méthode ne révèle pas de code qui est déclenché par l'utilisateur).

Donc, tout comme l'utilisation de détecteurs de mensonges dans la cour, ou le "goto" déclaration, nous ne conseillons pas de le faire, même si elles ont toutes leurs utilisations.