<para>Wenn man ein Programm entwickelt, dann ist einer der letzten Schritte es so schnell wie möglich (aber immer noch korrekt!) zu machen. Man will keine Zeit mit der Optimierung selten genutzter Funktionen verschwenden. Deshalb muss man wissen, in welchen Programmteilen dies meiste Zeit verbracht wird. </para>
<para>Diesen Vorgang nennt man Profiling. Das Programm wird dabei unter Kontrolle eines Profiling Werkzeuges ausgeführt, das ein Ablaufprotokoll erstellt. Nach der Auswertung des Ablaufprotokolls sollte man wissen, wo man optimieren muss. Man prüft den Optimierungserfolg mit einem weiteren Profiling Durchgang. </para>
<para>Sehr bekannt ist das GCC Profiling Werkzeug <application>gprof</application>: Dazu muss man das Programm mit der Option <option>-pg</option> kompilieren. Während der Ausführung erstellt das Programm eine Datei <filename>gmon.out</filename>, die mittels <command>gprof</command> in ein von Menschen lesbares Format umgewandelt werden kann. Der Nachteil dieser Methode ist, dass eine extra Kompilierung zur Erzeugung der vorbereiteten und statisch gelinkten ausführbaren Datei nötig ist. </para>
<para>Ein weiteres Profiling Werkzeug ist &cachegrind;, ein Teil von &valgrind;. Es benutzt die Prozessor Emulation von &valgrind; um die Datei auszuführen und protokolliert alle Speicherzugriffe im Ablaufprotokoll. Das Programm muss nicht neukompiliert werden. Man kann Shared Libraries und Plugins nutzen. Weiterhin hat der Profiling Vorgang keinen Einfluß auf das als Ergebnis des Profiling Vorgang entstehende Ablaufprotokoll. Das Ablaufprotokoll enthält die Anzahl von Instruktionen sowie Speicherzugriffe und die First/Second Level Cache Misses. Es findet eine Zuordnung auf die entsprechenden Quelltextzeilen und Funktionen des ausgeführten Programmes statt. Ein Nachteil ist die Verlangsamung um den Faktor 50 durch die Prozessor Emulation. </para>
<para>Ein Patch für die &valgrind; 1.0.x Quellen fügt die Protokollierung der Aufruffolge hinzu, z.B. welche Funktion welche aufgerufen hat und wieviel Ereignisse während der Abarbeitung einer Funktion auftreten. </para>
<para>&tdecachegrind; ist ein Darstellungswerkzeug für das mit &cachegrind; erzeugte Ablaufprotokoll. Man sollte unbedingt die Unterstützung für die Aufruffolge in &cachegrind; hinzufügen, denn &tdecachegrind; ist so wesentlich nützlicher. </para>
<para>Jedes Bildschirmelement in &tdecachegrind; verfügt über eine <quote>Was ist das?</quote> Hilfe. Möchte man nicht in dieser Dokumentation nachlesen, sollte man diese benutzen! </para>
<para>&tdecachegrind; ist nützlich für die späte Software Entwicklungs Etappe Profiling. Wenn man keine Anwendungen entwickelt, dann braucht man &tdecachegrind; nicht. </para>
<para>Dank an Julian Seward für seine einzigartige Anwendung &valgrind; und Nicholas Nethercote für den &cachegrind; Zusatz. Ohne diese Programme würde weder der Patch zur Aufruffolge (call tree) für &valgrind; noch <application>&tdecachegrind;</application> existieren. Viele Ideen für die Benutzeroberfläche stammen ebenfalls von ihnen. </para>
<para>Dank für die vielen Fehlerberichte/Vorschläge von verschiedenen Nutzern. Zum Schluß noch Dank an <itemizedlist>
<listitem><para>&kde;, das wundervolle Framework,</para>
<para>Die Homepage von &tdecachegrind; findet man unter <ulink url="http://www.weidendorfers.de/tdecachegrind">http://www.weidendorfers.de/tdecachegrind</ulink>. Dort gibt es weitere Installations- und Kompilierungshinweise. </para>
<para>Um &tdecachegrind; erfolgreich einsetzen zu können, benötigt man &kde; 3.x. Um die Ablaufprotokolle zu erzeugen, braucht man &cachegrind;. Um die sehr interessanten Visualisierungsmöglichkeiten von &tdecachegrind; ausschöpfen zu können, sollte man den Aufruffolge Patch von der &tdecachegrind; Homepage auf die Quellen von &valgrind; anwenden. </para>