Einer meiner Kollegen sagte mir ltrace(1)
. Es hat mir in der gleichen Situation sehr geholfen.
Angenommen, das gemeinsame Objekt Name Ihres C extention ist myext.so
und Sie wollen benchmark.py
auszuführen, dann
ltrace -x @myext.so -c python benchmark.py
Sein Ausgang ist wie
% time seconds usecs/call calls function
------ ----------- ----------- --------- --------------------
24.88 30.202126 7550531 4 ldap_result
12.46 15.117625 7558812 2 l_ldap_result4
12.41 15.059652 5019884 3 ldap_chase_v3referrals
12.41 15.057678 3764419 4 ldap_new_connection
12.40 15.050310 3762577 4 ldap_int_open_connection
12.39 15.042360 3008472 5 ldap_send_server_request
12.38 15.029055 3757263 4 ldap_connect_to_host
0.05 0.057890 28945 2 ldap_get_option
0.04 0.052182 26091 2 ldap_sasl_bind
0.03 0.030760 30760 1 l_ldap_get_option
0.03 0.030635 30635 1 LDAP_get_option
0.02 0.029960 14980 2 ldap_initialize
0.02 0.027988 27988 1 ldap_int_initialize
0.02 0.026722 26722 1 l_ldap_simple_bind
0.02 0.026386 13193 2 ldap_send_initial_request
0.02 0.025810 12905 2 ldap_int_select
....
Besondere Sorgfalt ist erforderlich, wenn Ihr gemeinsames Objekt hat -
oder +
in seinem Dateinamen. Diese Zeichen werden nicht so behandelt, wie sie sind (Details siehe).
Der Platzhalter *
kann eine Problemumgehung wie -x @myext*
anstelle von -x @myext-2.so
sein.
Vielen Dank für diesen Hinweis !! Ich habe tatsächlich nach dem gleichen gesucht. Ich werde es versuchen. – ThR37
EDIT: Es funktioniert in der Tat perfekt! Ein einfacher Wrapper mit Ctypes ist OK, auch wenn ich manchmal während der CPU Profilerstellung Segdefaults bekomme (aber das ist "normal" und im Doc erklärt ... Ich benutze x86_64 :() – ThR37
Vielen Dank für dieses kleine Nugget sehr, sehr nützlich :-) Was ich sehe, ist, dass pprof (oder eher, google-pprof im Paket für Debian) ist, dass ich nicht so viele Symbole wie beim Profiling des gleichen Codes entmagnetisiert bekomme mit Valgrind. Kann es sein, dass ich beim Kompilieren -pg angeben muss? – miquelramirez