detailiertere Performance-Ausgabe (val-, call-, kcachegrind)
-
Hi,
ich woltle mein Programm ein wenig schneller machen und dafür erstmal die Ursache finden.
Ich habe es mit g++ -g -O3 kompiliert, dann mit "valgrind --tool=callgrind ./name" ausgeführt und mir schließlich mit kcachegrind angeschaut.http://valgrind.org/docs/manual/cl-manual.html
http://kcachegrind.sourceforge.net/html/Home.htmlNun hat dort im CallGraph eine Unterfunktion über 90% der Laufzeit, diese wiederum ist aufgeteilt in 2 andere "<cycle 1>" und "exp <cycle 1>" . Diese haben jedoch nur 20% und 2%. Wo ist nun der Rest?
Gibt es eine Möglichkeit es noch detalierter anzuzeigen? So weit ich es finden konnte, habe ich im Graph die höchste tiefe aktiviert. "<cycle 1>" sagt mir zudem nix. Warum zeigt es die Namen der Unterfunktionen nicht mehr an?
Kann man die Laufzeit je Codezeile in dieser Funktion ausgeben?Gibt es noch bessere Möglichkeiten die Laufzeit zu messen?
Ich möchte wissen an welcher Stelle die 90%-Funktion am längsten braucht.
-
Der Rest der Laufzeit steckt dann in der 90%-Funktion selber.
Es ist bei vielen Profilern auch möglich, Teilabschnitte im Quellcode zur gesonderten Zählung zu markieren. Das ist ein Feature, das nützlicher klingt als es ist, denn bei optimierten, compilierten Code kann eine einzelne Codezeile weit verteilt werden. So wirklich Sinn macht das daher eher bei langen Funktionen mit mehreren logischen Teilabschnitten. In dem Fall stellt sich aber direkt die Frage, wieso man eine lange Funktion mit mehreren logischen Teilabschnitten hat, anstatt kleinen, klar abgegrenzten Funktionen.
Um dein konkretes Problem zu lösen, zeigst du uns am besten mal deine 90%-Funktion.
-
Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (alle ISO-Standards) in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
naja, die 90%-Funktion hat ja abgegrenzte Teilfunktionen, die des öfteren verwendet werden. In irgendeine Funktion müssen ja die Teilabschnitts-Funktionen auch rein. Die Funktion selbst hat sonst nur Speicherreservierung, ein paar Multiplikationen und eine Wurzel.
In den Teilfunktionen (~4), werden aber ca. 10 mal mehr Exponentialfunktionen (als Wurzel) und Multiplikationen (als außerhalb) berechnet. Ich nehme mal an, dass Wurzel nicht so vielfach komplizierter ist als exp. Bleibt also nur noch Speicherreservierung als einzigstes, was in den Teilfunktionen nicht öfter ausgeführt wird. Diese wird im Graph auch angegebn, jedoch nur mit 5%.
Es muss doch eine Möglichkeit geben, die Teilfunktionen der 90%-Funktion anzuzeigen.
Auch bei gprof sind sie nicht zu finden.
-
Die Funktionsaufrufe der fehlenden Funktionen werden wohl bei O3 inline optimiert worden sein. Du kannst ja mal inlining verbieten, wenn du ein Gefühl für die Dauer dieser Aufrufe bekommen möchtest.
Und wie ich schon gesagt habe, kann man auch Teile von Funktionen gezielt profilen, ich habe dich bloß gewarnt, dass das Ergebnis weniger aussagekräftig ist, als man meinen mag. Da du anscheinend nicht geschafft (oder nicht versucht?) hast, die Anleitung dafür zu finden:
http://valgrind.org/docs/manual/cl-manual.html#cl-manual.limits
http://valgrind.org/docs/manual/cl-manual.html#cl-manual.options.creation
Herauszufinden, wie es bei gprof geht, überlasse ich dir mal zur Übung.Und ich würde dir immer noch empfehlen, uns einfach mal den Code zu zeigen. Du erzählst etwas von Speicherallokationen. Das sind erfahrungsgemäß furchtbar teure Aktionen, die man in einer inneren Schleife dringend vermeiden möchte.
-
Perfrom schrieb:
Es muss doch eine Möglichkeit geben, die Teilfunktionen der 90%-Funktion anzuzeigen.
Ein sampling based Profiler wie CodeXL gibt die besten Resultate, da die abdeckung von den tatsaechlichen Kosten abhaengt.
