Empfehlungen für C-Profiler? [closed]

Jeder sagt immer, Sie sollten Ihr Programm profilieren, bevor Sie Optimierungen durchführen, aber niemand beschreibt jemals, wie das geht.

Was sind Ihre Praktiken für die Profilerstellung von C-Code?

Verwenden gcckompiliere und verlinke ich mit -pg (wie erklärt zB hier), fahren Sie dann fort, indem Sie das Programm ausführen (gemäß den Prinzipien, die auch unter dieser URL vorgeschlagen werden) und verwenden Sie gprof. Die Tools variieren, wenn Sie verschiedene Compiler &c verwenden, aber die URL wird auch dann noch empfohlen, für die Teile, die sich mit allgemeinen Ideen darüber befassen, wie und warum Sie Ihren Code profilieren sollten.

Wenn Sie Linux verwenden, dann empfehle ich die Kombination von ValGrind und CallGrind und KCacheGrind. ValGrind ist eine hervorragende Methode zum Auffinden von Speicherlecks, und die CallGrind-Erweiterung ist ein guter Profiler.

HINWEIS: Ich habe gerade gelernt dass ValGrind jetzt auch auf Mac OSX funktioniert. CallGrind und KCacheGrind wurden jedoch seit 2005 nicht mehr aktualisiert. Vielleicht möchten Sie sich das ansehen andere Frontends.

Gut, dass du gefragt hast 🙂 Wenn es Ihnen nichts ausmacht, konträr zu sein, überprüfen Sie diese Antworten:

• verbreitete Mythen
• kurzer Motivator
• tiefe Erklärung
• Live-Beispiel

Lassen Sie mich versuchen, es auf den Punkt zu bringen:

1. Wartet das Programm auf Sie oder warten Sie darauf? Wenn Sie nicht darauf warten müssen, haben Sie kein Problem, also lassen Sie es in Ruhe.

2. Wenn Sie warten müssen, fahren Sie fort.

Ich empfehle Sampling, also stroboskopische Röntgenaufnahmen dessen, was das Programm tut, wenn es beschäftigt ist (nicht auf Sie wartet). Holen Sie sich zumindest Proben des Aufrufstapels, nicht nur des Programmzählers. Wenn Sie nur Samples des Programmzählers erhalten, ist es bedeutungslos, wenn Ihr Programm viel Zeit mit I/O- oder Bibliotheksroutinen verbringt, also geben Sie sich nicht damit zufrieden.

Wenn Sie viele Proben erhalten möchten, benötigen Sie einen Profiler. Wenn Sie nur wenige benötigen, funktioniert die Pause-Schaltfläche im Debugger einwandfrei. Meiner Erfahrung nach sind 20 mehr als genug und 5 reichen oft aus.

Wieso den? Angenommen, Sie haben 1000 Beispiele der Aufrufliste. Jedes Sample stellt einen Bruchteil der Zeit dar, die aufgewendet wird nur weil jede einzelne Codezeile auf dem Stack dies angefordert hat. Wenn also eine Codezeile in 557 von 1000 Samples erscheint, können Sie davon ausgehen, dass sie für 557/1000 der Zeit verantwortlich ist, geben oder nehmen Sie ein paar Samples (15). Das heißt, wenn die gesamte Ausführungszeit Sie 100 $ gekostet hat, kostet diese Zeile allein 55,70 $, geben oder nehmen Sie 1,50 $ **, also sollten Sie prüfen, ob Sie sie wirklich brauchen.

Aber brauchen Sie 1000 Proben? Wenn diese Zeile etwa 55,7 % der Zeit kostet, dann würden Sie sie bei 10 Abtastungen auf 6 davon sehen, geben oder nehmen Sie 1,5 Abtastungen. Wenn Sie also eine Aussage zu 6 von 10 Proben sehen, wissen Sie, dass es Sie ungefähr zwischen 45 und 75 US-Dollar von diesen 100 US-Dollar kostet. Selbst wenn es nur 45 $ kostet, würden Sie nicht sehen wollen, ob Sie es wirklich brauchen?

Deshalb brauchen Sie nicht viele Proben – Sie brauchen nicht viel Genauigkeit. Was Sie brauchen, ist das, was Ihnen die Stack-Samples geben – sie zeigen Ihnen genau die wertvollsten Linien zur Optimierung.

** Die Standardabweichung der Anzahl der Proben ist sqrt( f * (1-f) * nsamp ) wo f ist der Anteil der Proben, die die Linie enthalten.

Der Vollständigkeit halber würde ich hinzufügen oprofil. Es ist besonders interessant, wenn Sie den Kernel benchmarken möchten.

Shark / Instruments (mit dtrace) sind die auf einem Mac verfügbaren Profiler. Sie sind ziemlich gut.

Visual Studio-Teamsystem kommt mit einem guten Profiler. Ebenfalls, Intel VTune ist nicht schlecht.