échantillon de temps Linux profileur basé

Question

version courte:

est-il un bon profileur d'échantillonnage basé sur le temps pour Linux?

version longue:

J'utilise généralement OProfile pour optimiser mes applications. J'ai récemment trouvé une lacune qui m'a fait me demander.

Le problème était une boucle serrée, générant C++ filt pour démêler un nom C++. J'ai seulement trébuché sur le code par accident tout en poursuivant un autre goulot d'étranglement. L'OProfile n'affichait rien d'inhabituel à propos du code, donc je l'ai presque ignoré mais mon sens du code m'a dit d'optimiser l'appel et de voir ce qu'il s'est passé. J'ai changé le popen de C++ filt à abi::__cxa_demangle. Le temps d'exécution est passé de plus d'une minute à un peu plus d'une seconde. À propos d'une accélération de x60.

Y a-t-il un moyen que j'aurais pu configurer OProfile pour marquer l'appel popen? Comme les données de profil se trouve maintenant OProfile pense que le col de la bouteille était le tas et std::string appels (BTW une fois optimisé a chuté l'exécution à moins d'une seconde, plus de x2 accélérer).

Voici ma configuration OProfile:

$ sudo opcontrol --status 
Daemon not running 
Event 0: CPU_CLK_UNHALTED:90000:0:1:1 
Separate options: library 
vmlinux file: none 
Image filter: /path/to/executable 
Call-graph depth: 7 
Buffer size: 65536 

Y at-il une autre profileur pour Linux qui aurait pu trouver le goulot d'étranglement?

Je suppose que le problème est que OProfile enregistre uniquement ses échantillons dans le processus en cours d'exécution. Je voudrais qu'il enregistre toujours ses échantillons dans le processus que je profile. Donc, si le processus est actuellement désactivé (blocage sur IO ou appel popen), OProfile placera simplement son échantillon à l'appel bloqué.

Si je ne peux pas résoudre ce problème, OProfile ne sera utile que si l'exécutable pousse près de 100% CPU. Il ne peut pas aider avec les exécutables qui ont des appels bloquants inefficaces.

Answer 1

Content de vous avoir demandé. Je crois que OProfile peut être fait pour faire ce que je considère comme la bonne chose, qui est de prendre des échantillons de pile sur l'horloge lorsque le programme est lent et, si cela ne vous permet pas d'examiner des échantillons de pile individuels, au moins résumer pour chaque ligne de code qui apparaît sur les échantillons, le pourcentage d'échantillons sur lesquels la ligne apparaît. C'est une directe mesure de ce qui serait sauvé si cette ligne n'était pas là. Here's one discussion.Here's another, et another. Et, comme Paul l'a dit, Zoom devrait le faire.

Si votre temps est passé de 60 sec à 1 sec, cela signifie que chaque échantillon de pile aurait eu une probabilité de 59/60 de vous montrer le problème.

Answer 2

Essayez Zoom - Je crois que cela vous permettra de profiler tous les processus - il serait intéressant de savoir si cela met en évidence votre problème dans ce cas.

Answer 3

rapidement piraté jusqu'à profileur d'échantillonnage trivial pour linux: http://vi-server.org/vi/simple_sampling_profiler.html

Il ajoute backtrace(3) un fichier sur SIGUSR1, et convertit ensuite à la source annotée.

Answer 4

j'ai écrit cela il y a longtemps, parce que je ne pouvais pas trouver quelque chose de mieux: https://github.com/dicej/profile

Je viens de découvrir cela aussi, bien que je ne l'ai pas essayé: https://github.com/oliver/ptrace-sampler