Linux-C++-Profiler

Das ist ganz einfach. Ich muss Linux C++-Programme profilieren:

Mussanforderungen :

  • kostenlos für nicht-kommerzielle Nutzung
  • mit gcc( g++) kompilierten Programmen arbeiten
  • mit x86-64Programmen arbeiten.
  • Profilprogramme, die mit Optimierungen kompiliert wurden, aktivieren ( -O3). (* siehe Fußnote)
  • Anzeige echter (entzerrter) Symbolnamen, auch bei aktivierter Optimierung. (* siehe Fußnote)

Nützliche Funktionen:

  • einfach zu verwenden für grundlegendes Profiling (den hotCode erkennen)
  • Zeilengranularität (welche Zeilen innerhalb einer Funktion sind heiß)
  • Granularität der Montageanleitung

Schöne Features wären:

  • GUI (auch Drittanbieter)
  • einfach zu installieren

Zukünftige Anforderungen (ich brauche es jetzt nicht, aber ich werde es in naher Zukunft brauchen):

  • Multithread-Programme profilieren
  • arbeiten mit clang(wäre schön)

Beispielsweise ist der Visual Studio Profiler unter Windows sehr gut.

Ich habe gprofes unter Linux versucht, konnte es aber nicht mit Optimierungsaktivierung zum Laufen bringen, nicht einmal mit -g -pg.

(*) Das Vorhandensein von Debug- und Profiling-Informationen kann erforderlich sein (z . B. -p -g -pg).

Ich habe O3 vergessen, aber perf_events, Oprofile und Valgrind (+Callgrind) sind wahrscheinlich die besten Kandidaten.

Antworten (3)

Ich profiliere meine Programme mit dem Valgrind - Plugin/Tool callgrind .

Für mich funktioniert dies unter x86_64 mit Optimierungen wie -O3beim Hinzufügen von Debugging-Symbolen mit -g. Valgrind ist unter der GPL lizenziert.

Die Ausgabe kann mit kcachegrind oder den Eclipse Linux Tools visualisiert werden

Das Callgrind-Handbuch gibt an, dass es Assembly-Analysen durchführen und mit Gabeln umgehen kann, wenn sie in der Quelle korrekt kommentiert sind.

Es ist einfach zu bedienen:

valgrind --tool=callgrind ./path/to/executable

Es führt das Programm langsamer als normal aus und erstellt eine Datei , callgrind.out.$pidin $pidder sich die PID des Aufrufs befindet (es ist die Nummer, die in jeder Zeile der Ausgabe von callgrind angezeigt wird ==$pid==).

Es kann dann in kcachegrind mit visualisiert werden

kcachegrind callgrind.out.$pid
Schade, dass callgrind zu langsam ist... Was ist mit gprof/sprof?

Sie sollten zumindest über die zufällige Pausentechnik Bescheid wissen . Es erfüllt nicht alle Ihre Anforderungen, aber es ist effektiver als jeder automatisierte Profiler, wenn es darum geht, das zu finden, was Sie "heißen" Code nennen, was ich "Möglichkeiten zur Beschleunigung" nenne.

Der Grund, warum es effektiver ist, ist folgender.

Stellen Sie sich einen idealen Profiler vor. Angenommen, es hat zufällige Stichproben des Programmzustands (einschließlich Stack und Speicher für alle Threads) genommen. Angenommen, es verfügt über künstliche Intelligenz und automatische Programmierfähigkeiten, sodass es sowohl das Programm als auch die Person verstehen kann, die es geschrieben hat. Angenommen, es untersuchte jede Probe und ermittelte den vollständigen Grund für diesen Zeitaufwand und suchte nach einer Möglichkeit, diesen Zeitaufwand zu vermeiden, indem möglicherweise etwas geändert wurde. Wenn es eine solche Gelegenheit zur Beschleunigung sieht und es auf Bruchteil X der Proben sieht, könnte es empfehlen, dass Sie durch diese Änderung bis zu Bruchteil X der Zeit sparen könnten.

Wäre das nicht ein toller Profiler? Es könnte alle möglichen Dinge finden, nicht nur Funktionen, die viel Zeit in Anspruch nehmen, für die Sie nichts tun können.

Es lohnt sich zu fragen - wie viele Proben müsste es nehmen? Die übliche Annahme ist - je mehr desto besser - bessere Präzision. FALSCH! Sie versuchen, das Problem zu finden , nicht es zu messen . Wenn eine Beschleunigungsmöglichkeit den Bruchteil X der Zeit in Anspruch nimmt, wird sie einen Bruchteil X von 10.000 Abtastungen und einen Bruchteil X von 10 Abtastungen (ungefähr) benötigen. Wenn es also groß genug ist, um es zu reparieren, braucht es nicht viele Proben. Tatsächlich muss es ein Problem nur zweimal sehen , um zu wissen, dass es wichtig ist. Im Durchschnitt benötigt es 2/X Samples, wenn also X 0,3 ist, benötigt es 6,67 Samples. (Die statistische Begründung ist hier .)

Nun, wenn es Ihnen nichts ausmacht, Ihren eigenen Kopf zu verwenden und ein paar Proben manuell zu nehmen, wie mit jstackoder einem Debugger, besitzen Sie bereits diesen idealen Profiler. Viele Programmierer wissen das und nutzen es, um ihren Code blitzschnell zu machen.

Dies ist keine Antwort auf die Frage nach einer Softwareempfehlung
@JanDoggen: Es wird die Verwendung eines Debuggers empfohlen, der mit jeder IDE- oder Compiler-Distribution geliefert wird. Ist das nicht Software? Ich weiß, dass es sehr schwer ist, die Prämisse in Frage zu stellen, dass Sie für die Profilerstellung ein Profiler-Tool benötigen, aber wenn Sie diese Prämisse nicht in Frage stellen, werden große Beschleunigungsfaktoren nicht gefunden. IMHO, der Grund, warum Programmierer Profiler mögen, ist, dass sie eine Bestätigungsverzerrung haben . Mit anderen Worten, sie hören gerne, dass es keine Möglichkeit gibt, ihren Code zu beschleunigen - er ist im Wesentlichen optimal, auch wenn das möglicherweise nicht stimmt.

Allinea MAP passt zu allem auf Ihrer Liste - es behandelt auch Ihre "zukünftigen Anforderungen" wie es Threads tut. Es gibt nichts Vergleichbares - es hat einen sehr geringen Overhead - normalerweise <5%, während Callgrind weit über 100% liegt.

Es ist kommerziell - aber im Interesse vollständiger Antworten gehört es hierher.

Ich habe Ihre Antwort positiv bewertet, muss aber der Vollständigkeit halber erwähnen, dass die günstigste Lizenz 635 GBP (950 US-Dollar) kostet.
Linux-C++-Profiler
AntwortenHierDatenschutz-Bestimmungen1y, 0v