2010-09-14 10 views
5

Die Profiler, mit denen ich Erfahrung habe (hauptsächlich der Digital Mars D Profiler, der mit dem Compiler kommt), scheinen die Ausführung des zu profilierenden Programms massiv zu verlangsamen. Dies hat einen großen Einfluss auf meine Bereitschaft, einen Profiler zu verwenden, da es das Profiling zu einem "echten" Lauf vieler meiner Programme macht, im Gegensatz zum Testen auf einem sehr kleinen Input, unpraktisch. Ich weiß nicht viel darüber, wie Profiler implementiert werden. Ist eine große (> 2x) Verlangsamung beim Profiling so ziemlich eine Tatsache des Lebens, oder gibt es Profiler, die es vermeiden? Wenn es vermieden werden kann, gibt es schnelle Profiler für D, vorzugsweise für D2 und vorzugsweise kostenlos?Machen alle Profiler die Ausführung erheblich verlangsamt?

Antwort

15

Ich weiß nicht über D-Profiler, aber im Allgemeinen gibt es zwei verschiedene Möglichkeiten, wie ein Profiler Profilinformationen sammeln kann.

Die erste ist durch Instrumentierung, indem Protokollierungsanrufe überall injiziert werden. Dies verlangsamt die Anwendung mehr oder weniger. In der Regel mehr.

Die zweite ist Sampling. Dann bricht der Profiler die Anwendung in regelmäßigen Abständen und inspiziert den Aufruf-Stack. Dies verlangsamt die Anwendung nicht sehr.

Der Nachteil eines Sampling-Profilers ist, dass das Ergebnis nicht so detailliert ist wie bei einem Instrumentierungsprofiler.

Überprüfen Sie die Dokumentation für Ihren Profiler, wenn Sie mit Probenahme statt Instrumentierung arbeiten können. Ansonsten haben Sie einige neue Google-Begriffe in "Sampling" und "Instrumentierung".

+0

++ Ja, Stichprobenregeln! Aber nicht irgendeine alte Probe. Sampling der Call-Stacks, zur Wanduhrzeit und Berichterstattung nach Zeilen (nicht Funktion) Prozent der Samples, die diese Zeile enthalten. Und die zusätzlichen Details, die Sie mit der Instrumentierung erhalten, sind sowieso nur Rauschen, wenn Sie den Code finden wollen, der optimiert werden muss. –

+0

Aus diesem Grund tendiere ich stark dazu, Sampling-Profiler zu bevorzugen, wo immer dies praktikabel ist - sie liefern viele zuverlässige Daten für relativ geringere Kosten und ich kann sie für eine lange Zeit einsetzen, um die Ergebnisse eines stochastischen, lauten Prozesses zu mitteln (wie eine Funktion, die 1ms 90% der Zeit dauert, die es genannt wird, und 500ms die anderen 10%). – Crashworks

+0

Ich finde die genaue Anzahl der Funktionsaufrufe, die von Zeit zu Zeit nützlich sind. Wenn ich 120 Kunden in einer Liste lade, schaue ich mir die Funktionen an, die 120 (und schlechter n x 120) mal genannt werden. Ich kann dann Funktionen finden, die versehentlich aufgerufen wurden (d. H. Ausgelöst durch ein Ereignis). Oder Anrufe für jeden Artikel, bei denen ein Anruf für alle von ihnen ausreichen sollte. –

1

Ich würde sagen, ja, beide Probenahme und Instrumentierung Formen der Profilerstellung wird Ihr Programm stark besteuern - unabhängig davon, wessen Profiler Sie verwenden, und in welcher Sprache.

+1

Viele Sampling-Profiler können skalieren, wie häufig sie ihre Samples nehmen. Dies ermöglicht, dass der Overhead erheblich geringer ist als das Instrumentierungsprofil (in der Größenordnung von 1-5%). Die Qualität der Daten hängt natürlich von der Abtastrate ab. Beide Profilierungsformen haben keine Auswirkungen von Null, aber die Stichprobenauswahl ist wesentlich geringer. –

1

Sie könnten versuchen, h3r3tic xfProf, die ein Sampling-Profiler ist. Habe es selbst nicht ausprobiert, aber dieser Typ ist immer cool stuff :)

Aus der Beschreibung:

Wenn das Programm nur ein paar hundert (oder tausend) mal pro Sekunde abgetastet wird, um die Leistung Overhead wird nicht bemerkbar sein.

+0

Danke. Dies sollte eine Verbesserung sein (habe es noch nicht getestet), obwohl es immer noch besagt, dass Sie ohne Optimierungen kompilieren müssen, was wahrscheinlich mehr als 2x Perf. Kosten. – dsimcha

+0

@dsimcha: @torhu: Ich habe gerade die xfProf-Seite überprüft. Ich bin traurig. Es basiert auf den gleichen Prinzipien wie gprof. Hier ist, warum das mich traurig macht: http://stackoverflow.com/questions/1777556/alternatives-to-gprof/1779343#1779343 –

2

My favorite method of profiling verlangsamt das Programm Weg Weg nach unten, und das ist in Ordnung. Ich laufe das Programm unter dem Debugger mit einer realistischen Last, und dann unterbreche ich es manuell. Dann kopiere ich den Call-Stack irgendwo, wie zum Beispiel Notepad. Es dauert also in der Größenordnung einer Minute, um eine Probe zu sammeln. Dann kann ich entweder die Ausführung fortsetzen, oder es ist sogar OK, um es von Anfang an neu zu beginnen, um ein anderes Beispiel zu bekommen.

Ich mache das 10 oder 20 mal, lange genug, um zu sehen, was das Programm tatsächlich aus einer Wanduhrperspektive macht. Wenn ich etwas sehe, das viel auftaucht, nehme ich mehr Samples, bis es wieder auftaucht. Dann stoppe ich und wirklich Studie, was es im Prozess ist und warum, die 10 Minuten oder mehr dauern kann. So finde ich heraus, ob diese Aktivität etwas ist, das ich durch effizienteren Code ersetzen kann, d. H. Es war nicht unbedingt notwendig.

Sie sehen, ich bin nicht interessiert zu messen, wie schnell oder langsam es geht. Das kann ich getrennt mit vielleicht nur einer Uhr machen.Ich bin daran interessiert herauszufinden, welche Aktivitäten einen großen Prozentsatz der Zeit (nicht Menge, Prozent), und wenn etwas einen großen Prozentsatz der Zeit dauert, ist das die Wahrscheinlichkeit, dass jeder Stapel es sehen wird.

Mit "Aktivität" meine ich nicht unbedingt, wo der PC hängt. In realistischer Software ist der PC irgendwo in einer System- oder Bibliotheksroutine fast immer ausgeschaltet. In der Regel sind Call-Sites in unserem Code wichtiger. Wenn ich zum Beispiel eine Folge von drei Aufrufen sehe, die auf der Hälfte der Stack-Samples angezeigt werden, stellt dies eine sehr gute Jagd dar, da, wenn eine davon nicht wirklich notwendig ist und beseitigt werden kann, die Ausführungszeit abfällt Hälfte.

Wenn Sie einen grinsenden Manager wollen, tun Sie das ein- oder zweimal.

Sogar in dem, was Sie denken würden, würde Mathe-schwere wissenschaftliche Zahl knirschende apps sein, wo Sie denken würden, Low-Level-Optimierung und Hotspots würden den Tag regieren, wissen Sie, was ich oft finde? Die mathematischen Bibliotheksroutinen sind Argumente überprüfen, nicht knirschen. Oft macht der Code nicht das, was er zu tun glaubt, und Sie müssen ihn nicht mit höchster Geschwindigkeit ausführen, um das herauszufinden.

+0

Weniger nützlich, wenn Sie ein eher flaches Profil haben, wo keine Komponente mehr als 2% der Ausführungszeit benötigt für sich selbst, aber Sie müssen Ihre Hauptschleife irgendwie von 40ms auf 33ms bringen, indem Sie fünfzig kleine Dinge reparieren. Aber das ist ein ziemlich spezieller Fall. – Crashworks

+0

Sie sollten auch einen Blick auf moderne Sampling Profiler werfen. Ich empfehle sie dir nicht, weil ich denke, dass deine Methode schlecht ist, sondern weil ich völlig mit deiner Herangehensweise einverstanden bin und glücklich bin, dass es automatische Werkzeuge gibt, die 1000 Proben pro Sekunde machen können. – Crashworks

+0

@ Crashworks: Danke. Meine Erfahrung ist, dass Sie nur zu dem Punkt kommen, winzige Dinge zu optimieren, nachdem Sie einige ziemlich massive Dinge losgeworden sind, die Sie noch nie vermutet hatten. Was Tools betrifft, denke ich, dass Zoom und LTProf die richtige Idee haben, aber wie ich zuvor versucht habe zu erklären, benötigt man keine große Anzahl von Samples, außer die größten Probleme sind wirklich sehr klein. Außerdem kenne ich kein Tool, mit dem Sie ein repräsentatives Stack-Sample im Detail und den Programmkontext zum Zeitpunkt der Aufnahme untersuchen können. Das gibt Ihnen Einsicht, dass Zahlen nicht können. –

Verwandte Themen