Je déboguise une candidature C et j'aimerais savoir combien de temps il dépense dans une fonction particulière.
Je pourrais changer le code source et ajouter un autre code pour faire la mesure, mais cela ne me semble pas juste. Je préférerais le faire avec une application externe, sans recompiler à chaque fois.
J'ai découvert qu'il est possible de mettre en place un point de rupture dans le GDB, donc je pensais, il doit être possible de suivre le temps en utilisant un outil similaire par simple procédure: - Définir un point d'arrêt - Lorsqu'il est arrêté, mesurez le temps réel et exécutez la fonction - Lorsque vous laissez la fonction, mesurez le temps à nouveau Cependant, je n'ai pas trouvé de manière à faire cela dans gdb: (
Des idées? Merci
5 Réponses :
Si vous utilisez GCC, vous souhaitez que l'option Compiler "-pg" et l'application GPROF .
GPROF me montrera compter le nombre de fois qu'une fonction a été appelée, mais ne veut pas me montrer des temps. Cela dit simplement "pas de temps accumulé"
Alors peut-être que c'était optimisé ou quelque chose.
Profilage est probablement ce que vous voulez. Jetez un coup d'œil à Prof ou GProf.
Mise à jour: après compilng avec "CC -WALL -GGDB -GGDB -PG -G3 -O2 DiskHash.c -o DiskHash" (et exécutant le programme), "GProf -P DiskHash" me donne :
Je vous suggère d'essayer Vous pouvez également essayer GPROF est uniquement fiable - dans mon expérience, ne fonctionne que du tout - si vous êtes statistiquement lien -pg versions compilé de chaque bibliothèque, y compris la bibliothèque C. Vous pouvez essayer pour faire cela à l'aide de l'option -Profile de GCC (qui fait ce que -pg est plus essaie de sous-in -pg < / Code> Bibliothèques) Mais le problème est que GNU Libc n'aime vraiment pas être lié statilement et que votre distribution peut ne pas fournir les versions compilées -pg de chaque bibliothèque dont vous avez besoin.
cachegrind , lequel est un Valgrind mode de fonctionnement et nécessite uniquement des informations de débogage pour tout. C'est beaucoup plus facile à obtenir. La capture est, il a d'énormes frais généraux; si énorme qu'il pourrait invalider vos tests. Attendre au moins un ralentissement 2x.
perf - si vous peut mettre vos mains sur une copie. C'est très intelligent, mais c'est de, par et pour les pirates hacheurs de noyau qui pensent que les gens comme des choses de construction à partir de zéro. J'ai eu beaucoup de chance avec ça. (Lisez http://web.eecs.utk.edu/~vweaver1 / Projets / Perf-Events / qui concerne l'API sous-jacente, pas l'utilitaire, mais pourrait toujours vous éviter de beaucoup de temps perdu.)
J'ai une fonction d'assistant dans mon ~ / .gdbinit: Vous devrez peut-être ajuster le 1000000 en fonction de votre implémentation de horlogs_per_sec sur votre plate-forme. P> L'utilisation est triviale; Exécutez l'aide qui exécutera la prochaine étape et donnera des informations de synchronisation: P> Breakpoint 2, install_new_payload_from_meta (snmp_meta=0x7eee81c0, pkt=0x0, entry=0x7d4f4e58) at /home/sgillibr/savvi-dc-snmp/recipies.c:187
(gdb) timeme 100000
***long***
580000 cycles, 0.580000 seconds
(gdb)
Je l'ai essayé pour la fonction de sommeil () dans le fichier C, il ne fonctionne pas, le résultat est toujours 0.
mettre cela dans votre ~ / .gdbinit type timeme ou TI lorsque vous souhaitez mesurer l'heure de la prochaine fonction .