2010-11-13 4 views
3

Disons que j'ai un programme artificiel:Comment localiser le temps d'inactivité (et l'heure d'E/S du réseau, etc.) dans XPerf?

#include <Windows.h> 

void useless_function() 
{ 
    Sleep(5000); 
} 

void useful_function() 
{ 
    // ... do some work 
    useless_function(); 
    // ... do some more work 
} 

int main() 
{ 
    useful_function(); 
    return 0; 
} 

Objectif: Je veux que le profileur pour me dire useful_function() appelle inutilement useless_function() qui attend aucune raison évidente. Sous XPerf, cela n'apparaît dans aucun des graphiques que j'ai parce que l'appel à WaitForMultipleObjects() semble être comptabilisé à Idle.exe au lieu de mon propre programme.

Et voici la ligne de commande XPerf que je dirige actuellement:

xperf -on Latency -stackwalk Profile 

Toutes les idées?

(Ce ne se limite pas à attendre les fonctions. Ci-dessus aurait pu être résolu en plaçant des points d'arrêt à NtWaitForMultipleObjects. Pourrait être idéal il un moyen de voir l'échantillon de pile qui est prend beaucoup de temps-horloge murale par opposition à seulement le temps CPU)

Répondre

0

Ce "profileur" vous le dira - faites juste quelques pauses au hasard et regardez la pile. Si do some work prend 5 secondes, et do some more work prend 5 secondes, puis 33% du temps la pile ressemblera à ceci

main: calling useful_function 
useful_function: calling useless_function 
useless_function: calling Sleep 

donc à peu près 33% de vos échantillons de pile montrera exactement cela. Toute ligne de code coûtant une fraction de l'heure de l'horloge apparaît sur cette fraction d'échantillons.

Sur le reste des échantillons, vous le verrez faire les autres choses.

Il existe des profileurs automatiques qui font la même chose d'une manière plus jolie, tels que Zoom et LTProf, bien qu'ils ne vous montrent pas vraiment les échantillons.

J'ai regardé le xperf doc, en essayant de comprendre si vous pouviez obtenir des échantillons de la pile sur l'horloge murale et obtenir des pourcentages à la résolution au niveau de la ligne. Il semble que vous devez être sur Windows 7 ou Vista. Ils se contentent de fonctions, pas de lignes, ce qui est important si vous avez des fonctions réalistes. Je ne pouvais pas comprendre comment avoir accès aux échantillons individuels, ce qui je pense est important pour voir pourquoi le programme passe son temps.

+0

Merci Mike. J'ai lu beaucoup de vos articles sur la technique du "sampling manuel". C'est vraiment utile. D'autre part, Windows XPerf est un excellent outil pour profiler les programmes - il a une trace de pile pour l'E/S sur disque, les changements de contexte et ** l'utilisation du tas **, etc. L'horloge murale IMO est la seule pièce manquante. sinon outil gratuit complet. BTW le site officiel de LTProf semble être en panne pour le moment: P – kizzx2

+0

@ kizzx2: Oui, pour l'utilisation du tas, je n'ai pas d'opinion cohérente. Si je rencontre un aspect négatif sur xperf (et d'autres outils), je ne le souhaite vraiment pas, mais j'essaie de faire la lumière sur ce qui doit être réparé et pourquoi. Pour LTProf, j'ai acheté une copie, car il semblait que tout ce qu'il y avait de mieux en dessous. Ensuite, j'ai trouvé 1) vous ne pouvez pas l'étrangler manuellement dans une application d'interface utilisateur, et 2) pour la présentation, ils donnent le pourcentage par fonction, et le pourcentage de ligne est relatif à la fonction. Donc, si vous voulez connaître le pourcentage réel, vous devez multiplier ces deux. Ensuite, il reste la question de rendre les échantillons visibles. –

+0

@ kizzx2: ... Ce dernier point est probablement quelque chose de fondamental, et je me sens vraiment à ce sujet. C'est la différence entre simplement mesurer les choses et comprendre réellement pourquoi le programme passe certaines fractions de son temps. Je vois des piles 30 couches de profondeur et elles semblent totalement confuses, mais si je prends le temps de le lire et de regarder le code à différents niveaux, et les données, alors je peux vraiment comprendre si ce qu'il fait * doit être fait, et c'est la clé. –

2

Je pense que ce que vous recherchez est l'analyse Wait avec la fonctionnalité Ready Thread dans Xperf. Il capture chaque changement de contexte et vous donne la pile d'appel du thread une fois qu'il se réveille de veille (ou une opération autrement bloquée). Dans votre cas, vous verriez la pile juste après l'appel de veille (5000) ainsi que le temps passé à dormir.

La fonctionnalité est un peu obscure à utiliser. Mais il est fort heureusement bien décrit ici:

Use Xperf's Wait Analysis for Application-Performance Troubleshooting

1

Analyse d'attente est la façon de le faire.Vous devez:

  • Enregistrez le fournisseur de cDébranchez, afin d'obtenir tous les changements de contexte
  • enregistrement des piles d'appel sur les changements de contexte en ajoutant + cDébranchez à votre argument -stackwalk
  • piles d'appels probablement enregistrer sur le fil prêt pour obtenir plus d'informations sur qui vous préparions (c.-à, qui a publié le Mutex ou CS ou sémaphores et où) en ajoutant + READYTHREAD à votre -stackwalk

Ensuite, vous utilisez l'utilisation du processeur (précise) dans WPA (ou xperfview, mais c'est ancien) pour regarder les commutateurs de contexte et fin d où votre TimeSinceLast est haut sur un thread qui ne devrait pas être inactif. Vous aurez généralement voulez les colonnes dans l'utilisation du CPU (précise) dans ce genre d'ordre:

  • NewProcess (votre processus étant commuté)
  • NewThreadId
  • NewThreadStack
  • ReadyingProcess (qui a fait votre fil prêt à fonctionner)
  • ReadyingThreadId (en option)
  • ReadyThreadStack (option, + ReadyThread sur -stackwalk)
  • barre orange
  • comte
  • TimeSinceLast (us) - trier par cette colonne, généralement
  • Quelle que soit d'autres colonnes que vous voulez

Pour plus de détails voir ces articles particuliers de mon blog: - https://randomascii.wordpress.com/2014/08/19/etw-training-videos-available-now/ - https://randomascii.wordpress.com/2012/06/19/wpaxperf-trace-analysis-reimagined/

Questions connexes