<?xml version="1.0" ?> <!DOCTYPE book PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd" [ <!ENTITY kcachegrind '<application >KCachegrind</application >'> <!ENTITY cachegrind "<application >Cachegrind</application >"> <!ENTITY calltree "<application >Calltree</application >"> <!ENTITY callgrind "<application >Callgrind</application >"> <!ENTITY valgrind "<application >Valgrind</application >"> <!ENTITY oprofile "<application >OProfile</application >"> <!ENTITY EBS "<acronym >EBS</acronym >"> <!ENTITY TBS "<acronym >TBS</acronym >"> <!ENTITY kappname "&kcachegrind;"> <!ENTITY package "kdesdk"> <!ENTITY % addindex "IGNORE"> <!ENTITY % German "INCLUDE"> ]> <book lang="&language;"> <bookinfo> <title >Das Handbuch zu &kcachegrind;</title> <authorgroup> <author ><firstname >Josef</firstname > <surname >Weidendorfer</surname > <affiliation > <address ><email >Josef.Weidendorfer@gmx.de</email ></address> </affiliation> <contrib >Ursprünglicher Autor der Dokumentation</contrib> </author> <author ><firstname >Federico</firstname > <surname >Zenith</surname > <affiliation > <address ><email >federico.zenith@member.fsf.org</email ></address> </affiliation> <contrib >Aktualisierung und Korrekturen</contrib> </author> <othercredit role="translator" ><firstname >Thomas</firstname ><surname >Reitelbach</surname ><affiliation ><address ><email >tr@erdfunkstelle.de</email ></address ></affiliation ><contrib >Deutsche Übersetzung</contrib ></othercredit > </authorgroup> <copyright> <year >2002-2004</year> <holder >&Josef.Weidendorfer;</holder > </copyright> <copyright> <year >2009</year> <holder >Federico Zenith</holder> </copyright> <legalnotice >&FDLNotice;</legalnotice> <date >2009-10-07</date> <releaseinfo >0.5.1</releaseinfo> <abstract> <para >&kcachegrind; ist ein KDE-Werkzeug zur Visualisierung von Profildaten. </para> </abstract> <keywordset> <keyword >KDE</keyword> <keyword >kdesdk</keyword> <keyword >Cachegrind</keyword> <keyword >Callgrind</keyword> <keyword >Valgrind</keyword> <keyword >Profiling</keyword> </keywordset> </bookinfo> <chapter id="introduction"> <title >Einleitung</title> <para >&kappname; ermöglicht das Durchsehen der von einem Profiler erzeugten Profildaten. In diesem Kapitel wird erklärt, warum man Profildaten erhebt und wie man sie erzeugt. Außerdem werden einige verfügbare Profiler-Werkzeuge vorgestellt. </para> <sect1 id="introduction-profiling"> <title >Profiling</title> <para >Bei der Entwicklung einer Anwendung gehört es zu den abschließenden Schritten, es in der Geschwindigkeit zu optimieren. Es ist natürlich nicht sinnvoll, die Funktionen zu optimieren, die selten aufgerufen werden. Daher muss der Programmautor wissen, in welchem der Programmabschnitt die meiste Zeit verbraucht wird. </para> <para >Für sequentiell ablaufenden Code reicht es in der Regel aus, statistische Daten über die Laufzeiteigenschaften des Programms zu ermitteln. Dazu gehört die in bestimmten Funktionen verbrachte Zeit und die zugehörigen Codezeilen. Das Erheben dieser Daten nennt man Profiling. Dabei läuft das Programm in einer kontrollierten Laufzeitumgebung des Profiling-Werkzeugs ab, welches am Ende des Durchlaufs eine Zusammenfassung der gesammelten Daten ausgibt. Im Gegensatz dazu gibt es auch parallel ablaufenden Code. Geschwindigkeitsprobleme resultieren hier häufig daraus, dass ein Prozessor auf Daten eines anderen Prozessors warten muss. Diese Wartezeit lässt sich nicht ohne Weiteres ermitteln und zuordnen; in einem solchen Fall müssen Ereignisse mit Hilfe von Zeitstempeln rückverfolgt werden. Diese Art Daten kann &kcachegrind; nicht anzeigen. </para> <para >Nach der Analyse der erzeugten Profiling-Daten sollte es ein Leichtes sein, den möglichen Flaschenhals im Code aufzufinden. Beispielsweise kann man den Code in besonders häufig aufgerufenen Funktionen optimieren. Danach sollte man den Erfolg der Optimierungen mit einem erneuten Profiler-Durchlauf überprüfen. </para> </sect1> <sect1 id="introduction-methods"> <title >Profiling-Methoden</title> <para >Um verbrauchte Zeit zu messen oder eingetretene Ereignisse in einem bestimmten Code-Bereich aufzuzeichnen (⪚ einer Funktion) muss zusätzlicher Code vor und hinter dem fraglichen Bereich einprogrammiert werden. Dieser Code misst dann die Zeit oder liest einen globalen Ereigniszähler aus und berechnet die Unterschiede. Diese Veränderung des Original-Codes nennt man Instrumentieren. Die Instrumentierung kann der Programmierer, der Compiler oder auch die Laufzeitumgebung einrichten. Die fraglichen Code-Bereiche sind zumeist verschachtelt und der Aufwand für die Messung dieser Bereiche beeinflusst immer auch die Messergebnisse. Daher sollte die Methode der Instrumentierung nur in ausgewählten Bereichen angewandt und die Ergebnisse mit Bedacht ausgewertet werden. Dieser Umstand macht eine wirklich exakte Messung zu einer äußerst komplexen Aufgabe.</para> <para >Eine exakte Messung ist dennoch möglich, nämlich mit Hilfe von Hardware-Zählwerken, so wie sie in den heutigen modernen Prozessoren vorkommen. Diese Zähler inkrementieren mit jedem auftretenden Ereignis. Wir möchten auftretende Ereignisse bestimmten Code-Bereichen zuordnen können. Ohne Hardware-Zähler müssten wir jedes Ereignis selbst mit Hilfe von Software zählen - was natürlich nicht möglich ist. Unter der Annahme, dass die Ereignisverteilung im Quell-Code gleichmäßig ist, wurde jedoch eine Methode entwickelt, die nur jedes n-te Ereignis untersucht - wodurch die <quote >Kosten</quote > der Messung beeinflussbar sind: Sampling. Zeitbasiertes Sampling (Time Based Sampling, &TBS;) untersucht in regelmäßigen Zeitabständen den Programmzähler und erzeugt ein Histogramm über den Programmcode. Das ereignisbasierte Sampling (Event Based Sampling, &EBS;) untersucht im Gegensatz dazu den Hardware-Zähler moderner Prozessoren. Dazu wird eine Interrupt-Leitung verwendet, die bei einem Zähler-Niedrigstand auslöst; daraufhin wird ein Histogramm der zugehörigen Ereignisverteilung erzeugt: Innerhalb dieser Routine wird der Ereigniszähler wieder auf das Element <symbol >n</symbol > der Sampling-Methode zurückgesetzt. Der Vorteil des Sampling ist, dass der Programmcode nicht verändert werden muss. Aber es handelt sich immer noch um eine Kompromisslösung: Die Methode misst genauer, wenn <symbol >n</symbol > möglichst klein ist. Mit schrumpfendem <symbol >n</symbol > steigt jedoch auch die Auslastung des Interrupt-Handlers.</para> <para >Eine weitere Messmethode ist es, bestimmte Ereignisse im Rechner zu simulieren, während der fragliche Code läuft; eine geführte Simulation. Eine solche Simulation wird von einem mehr oder weniger genauen Rechnermodell abgeleitet. Mit exakten Rechnermodellen sind ziemlich genaue Rückschlüsse auf die Realität möglich - jedoch ist der für solche Tests nötige Zeitaufwand in der Praxis oft inakzeptabel. Der Vorteil einer Simulation ist, dass im Grunde beliebig komplexer Messungs-Code in den Quell-Code eingefügt werden kann, ohne die Messergebnisse zu beeinflussen. Dies direkt vor der Ausführung (Laufzeit-Instrumentierung) mit der Original-Binärdatei durchgeführt ist für den Benutzer sehr komfortabel: Es ist kein erneutes Kompilieren erforderlich. Eine Simulation ist dann sinnvoll, wenn nur Teile einer Maschine mit einem einfachen Modell simuliert werden sollen. Ein weiterer Vorteil ist, dass die Messergebnisse aus Simulationen einfacher Rechnermodelle auch leichter zu interpretieren sind: oftmals ist das Problem mit echter Hardware, dass sich Ereignisse verschiedener Rechnermodule überschneiden.</para> </sect1> <sect1 id="introduction-tools"> <title >Profiling-Werkzeuge</title> <para >Am bekanntesten ist der GCC-Profiler <application >gprof</application >: Man muss das Programm mit der Option <option >-pg</option > kompilieren. Bei der Programmausführung wird dann eine Datei namens <filename >gmon.out</filename > erzeugt, die mittels <command >gprof</command > in ein leserliches Format umgewandelt werden kann. Ein Nachteil ist natürlich das notwendige Rekompilieren des Programms, welches außerdem statisch gelinkt werden muss. In diesem Fall wird die compilergenerierte Instrumentierung angewandt - alle Aufrufe rund um Funktionen und die zugehörigen Funktionsaufrufe werden gemessen. Zusammen mit zeitbasiertem Sampling (&TBS;) ergibt sich daraus ein Histogramm der Verteilung der verbrauchten Zeit im Code. Aus den beiden Zeiten lässt sich die Zeit errechnen, die ein Programm in bestimmten Funktionen und den von dort aufgerufenen Funktionen verbringt. </para> <para >Es gibt auch Bibliotheken zur exakten Messung aufgetretener Ereignisse. Diese sind in der Lage, Hardware-Zeitgeber auszulesen. Am bekanntesten sind der Patch PerfCtr für &Linux; und die architekturunabhängigen Bibliotheken PAPI und PCL. Dennoch ist zur exakten Messung eine Instrumentierung des Codes nötig. Man kann dazu entweder die Bibliotheken selbst oder automatische Systeme wie ADAPTOR (für FORTRAN-Quellcode) oder DynaProf (Code-Einschleusung über DynInst) verwenden.</para> <para >&oprofile; ist ein systemweites Profiling-Werkzeug für &Linux;. Es verwendet Sampling. </para> <para >Eine sehr komfortable Möglichkeit des Profiling ist es jedoch, &cachegrind; oder &callgrind; zu verwenden. Dabei handelt es sich um Simulatoren, die auf das Instrumentierungs-Grundgerüst von &valgrind; aufsetzen. Diese sind eine gute Alternative zu den anderen Profiling-Werkzeugen, weil keine Hardware-Zähler verwendet werden (oftmals ist das mit heutigen &Linux;-Installationen schwierig) und die Programmdateien nicht verändert werden müssen. Der Nachteil einer Simulation ist natürlich die Geschwindigkeitseinbuße. Diese kann allerdings reduziert werden, indem man die Simulation auf die interessanten Programmabschnitte beschränkt. Ohne Messung bzw. Simulation der Instrumentierung reduziert &valgrind; die Geschwindigkeit um den Faktor 3 bis 5. Wenn nur das Aufruf-Diagramm und die Anzahl der Funktionsaufrufe von Interesse sind, kann man den Cache-Simulator ganz ausschalten. </para> <para >Die Cache-Simulation ist der erste Schritt zur Abschätzung der echten Zeiten, da die Laufzeit von Programmen stark abhängig ist von der Ausnutzung des sogenannten Aufruf-<emphasis >Caches</emphasis > (kleine und sehr schnelle Puffer, die erneuten Zugriff auf die gleichen Speicherbereiche erheblich beschleunigen). &cachegrind; führt eine Cache-Simulation durch, in der die Speicheradressen abgefangen werden. Die erhobenen Daten enthalten auch die Anzahl der Instruktionen, Zugriffe auf Daten-Bereiche im Cache sowie fehlgeschlagene Zugriffe auf den Cache der ersten und zweiten Stufe. Diese Informationen werden den entsprechenden Code-Zeilen und Funktionen des Programms zugeordnet. Durch eine geschickte Kombination der erhaltenen Daten lässt sich eine gute Abschätzung der benötigten Zeit ermitteln. </para> <para >&callgrind; ist eine Erweiterung für &cachegrind;, die das Aufruf-Diagramm eines Programms zur Laufzeit erzeugt. Ein Aufruf-Diagramm gibt Auskunft darüber, welche Funktionen die anderen Funktionen aufrufen und wieviele Ereignisse in einem Funktionsdurchlauf abgearbeitet werden. Des Weiteren können die zu sammelnden Profiler-Daten nach Threads und Aufrufketten-Kontext unterteilt werden. Mit Callgrind ist es möglich, Profiling-Daten auf Instruktions-Ebene zu erhalten und damit auch disassemblierten Code zu untersuchen. </para> </sect1> <sect1 id="introduction-visualization"> <title >Darstellung</title> <para >Profiling-Werkzeuge erzeugen für gewöhnlich eine sehr große Datenmenge. Durch diese sollte man möglichst einfach im Aufruf-Diagramm auf und ab navigieren können. Außerdem kann schnell und komfortabel zwischen verschiedenen Sortier-Modi für Funktionen und verschiedenen Ansichten für Ereignistypen umgeschaltet werden. Es bietet sich daher an, diese Aufgabe einem Programm mit grafischer Oberfläche zu überlassen. </para> <para >&kappname; ist eine grafisches Visualisierungswerkzeug für Profiling-Daten und erfüllt all diese Wünsche. Obwohl das Programm ursprünglich programmiert wurde, um die Daten von &cachegrind; und &calltree; anzuzeigen, gibt es auch Konverter, mit denen sich Daten anderer Profiling-Werkzeuge anzeigen lassen. Im Anhang finden Sie auch eine Beschreibung des Datenformats von &cachegrind;/&callgrind;. </para> <para >Neben einer Liste der Funktionen sortiert nach exklusiven und inklusiven Kosten, optional gruppiert nach Quelldatei, Bibliothek oder C++-Klasse, unterstützt &kappname; mehrere Ansichten einer ausgewählten Funktion. Im Einzelnen sind dies: <itemizedlist> <listitem ><para >eine Aufruf-Diagramm-Ansicht, die den Bereich des Aufruf-Diagramms um die gewählte Funktion darstellt,</para> </listitem> <listitem ><para >eine Baumansicht, die die Beziehungen eingebetteter Aufrufe zueinander darstellt, (mit den inklusiven Kosten zur schnellen Ermittlung problematischer Funktionen),</para> </listitem> <listitem ><para >eine Quellcode- und Disassembler-Ansicht, die Details zu den Kosten einzelner Quelltextzeilen und Assembler-Anweisungen darstellt.</para> </listitem> </itemizedlist> </para> </sect1> </chapter> <chapter id="using-kcachegrind"> <title >&kcachegrind; verwenden</title> <sect1 id="using-profile"> <title >Visualisierungsdaten erheben</title> <para >Als erstes müssen Geschwindigkeitsdaten erzeugt werden. Dafür misst man bestimmte Laufzeit-Eigenschaften eines Programms mit einem Profiling-Werkzeug. &kcachegrind; selbst enthält kein Profiling-Werkzeug, kann aber gut mit &callgrind; zusammenarbeiten. Wenn man einen Konverter einsetzt, können auch die von &oprofile; erzeugten Profiler-Daten visualisiert werden. Eine Erklärung der genauen Bedienung dieser Programme würde den Rahmen dieses Handbuchs sprengen; im folgrenden Kapitel erhalten Sie dennoch eine kurze Schnellstart-Einführung. </para> <sect2> <title >&callgrind;</title> <para >&callgrind; ist ein Bestandteil von <ulink url="http://valgrind.org" >&valgrind;</ulink >. Früher hieß das Programm &calltree;, der Name war jedoch sehr irreführend. </para> <para >Am häufigsten wird das Programm benutzt, indem <userinput ><command >valgrind</command > <option >--tool=callgrind</option > </userinput > dem Befehlszeilenaufruf der Anwendung vorangestellt wird. Zum Beispiel: <blockquote ><para ><userinput > <command >valgrind</command > <option >--tool=callgrind</option > <replaceable >meinprogramm</replaceable > <replaceable >meineargumente</replaceable > </userinput ></para ></blockquote >Beim Programmende wird die Datei <filename >callgrind.out.<replaceable >pid</replaceable ></filename > erzeugt, die Sie dann in &kcachegrind; laden können. </para> <para >Eine fortgeschrittenere Methode ist es, Profiling-Daten immer nur dann zu erzeugen, wenn eine bestimmte Funktion Ihres Programms aufgerufen wird. Wenn Sie beispielsweise für &konqueror; die Profiling-Daten zum Rendern einer Webseite erzeugen möchten, könnten Sie Daten erheben, wenn der Menüeintrag Ansicht/Aktualisieren benutzt wird (dies ist gleichzusetzen mit einem Aufruf von <menuchoice ><guimenu >Ansicht</guimenu ><guimenuitem >Erneut Laden</guimenuitem ></menuchoice >). Dies entspricht dem Aufruf von <methodname >KonqMainWindow::slotReload</methodname >. Benutzen Sie dazu den folgenden Aufruf: <blockquote ><para ><userinput > <command >valgrind</command > <option >--tool=callgrind</option > <option >--dump-before=KonqMainWindow::slotReload</option > <replaceable >konqueror</replaceable ></userinput ></para ></blockquote > Dadurch werden mehrere Profiler-Dateien erzeugt, jede mit einer eindeutigen, aufsteigenden Nummer im Dateinamen. Es wird auch eine Datei ohne aufsteigende Nummer erzeugt. Diese können Sie in &kcachegrind; laden; die Folgedateien werden automatisch auch geladen und können in der <guilabel >Komponenten-Übersicht</guilabel > und <guilabel >Komponenten</guilabel >-Liste betrachtet werden. </para> </sect2> <sect2> <title >&oprofile;</title> <para >&oprofile; finden Sie unter <ulink url="http://oprofile.sf.net" >http://oprofile.sf.net</ulink >. Folgen Sie der Installationsanleitung auf der Webseite. Bevor Sie dies allerdings tun, prüfen Sie, ob das Programm bereits von Ihrer Distribution mitgeliefert wird (so ⪚ bei &SuSE;). </para> <para >Systemweites Profiling ist nur dem Systemverwalter erlaubt, da so alle Aktionen im System überwacht werden können. Die folgenden Schritte müssen Sie also als Systemverwalter ausführen. Richten Sie zuerst den Profiling-Prozess ein; mit der &GUI; <command >oprof_start</command > oder mit dem Befehlszeilenprogramm <command >opcontrol</command >. Der Timer-Modus (&TBS;, siehe Einführung) sollte voreingestellt sein. Um die Messung zu starten, führen Sie <userinput ><command >opcontrol</command > <option >-s</option ></userinput > aus. Starten Sie nun die Anwendung an deren Werten Sie interessiert sind und führen Sie anschließend <userinput ><command >opcontrol</command > <option >-d</option ></userinput > aus. Die Messergebnisse werden in Dateien im Ordner <filename class="directory" >/var/lib/oprofile/samples/</filename > gespeichert. Um die Daten zu betrachten, führen Sie <blockquote ><para ><userinput > <command >opreport</command > <option >-gdf</option > | <command >op2callgrind</command > </userinput ></para ></blockquote > in einem leeren Ordner aus. Es wird für jedes auf dem Systen laufende Programm eine Datei angelegt, die für sich in &kcachegrind; geöffnet werden kann. </para> </sect2> </sect1> <sect1 id="using-basics"> <title >Grundlagen der Benutzeroberfläche</title> <para >Wenn Sie &kcachegrind; mit einer Profildaten-Datei als Argument starten, oder nachdem Sie über <menuchoice ><guimenu >Datei</guimenu > <guimenuitem >Öffnen</guimenuitem > </menuchoice > eine Datei geöffnet haben, sehen Sie eine Navigationsleiste mit der Liste der Funktionen links und dem Hauptbereich rechts, in dem die ausgewählte Funktion dargestellt wird. Dieser Bereich kann so eingerichtet werden, dass er mehrere Ansichten anzeigt. </para> <para >Beim ersten Start ist dieser Bereich in zwei übereinander angeordnete Ansichten aufgeteilt, jede Ansicht kann auswählbare Unterfenster enthalten. Benutzen Sie das Kontextmenü der Unterfensterreiter oder den Trennbalken, um diese Ansichten anzupassen, Um schnell zwischen den verschiedenen Ansichten zu wechseln, benutzen Sie <menuchoice ><shortcut ><keycombo action="simul" >&Ctrl;<keycap >Pfeil rechts</keycap > </keycombo ></shortcut > <guimenu >Ansicht</guimenu ><guisubmenu >Layout</guisubmenu > <guimenuitem >Nächstes Layout</guimenuitem ></menuchoice > und <menuchoice ><shortcut ><keycombo action="simul" >&Ctrl;<keycap >Pfeil links</keycap > </keycombo ></shortcut > <guimenu >Ansicht</guimenu ><guisubmenu >Layout</guisubmenu > <guimenuitem >Vorheriges Layout</guimenuitem ></menuchoice >. </para> <para >Der aktuelle Ereignistyp ist wichtig für die Darstellung: Für &callgrind; ist das zum Beispiel <quote >Cache Misses</quote > oder <quote >Cycle Estimation</quote >; für &oprofile; im einfachsten Fall <quote >Timer</quote >. Sie können den Ereignistyp mit dem Kombinationsfeld in der Werkzeugleiste oder in der <guilabel >Ereignistyp</guilabel >-Ansicht ändern. Wenn Sie die Funktion <function >main</function > wählen und einen Blick auf den Aufruf-Graphen werfen, sehen Sie einen ersten Überblick über die Laufzeit-Charakteristik. Sie sehen dort die Aufrufe, die von Ihrem Programm getätigt wurden. Beachten Sie, dass die Aufruf-Graph-Ansicht nur Funktionen anzeigt, die eine hohe Anzahl Ereignisse aufweisen. Wenn Sie im Aufruf-Graphen auf eine Funktion klicken, werden die aufgerufenen Funktionen um die ausgewählte herum angezeigt. </para> <para >Um die &GUI; besser kennen zu lernen, lesen Sie zusätzlich zu diesem Handbuch auch den Dokumentationsabschnitt auf der Webseite <ulink url="http://kcachegrind.sf.net" >http://kcachegrind.sf.net</ulink >. Zudem hat jedes Element in &kcachegrind; eine <quote >Was ist das</quote >-Hilfe. </para> </sect1> </chapter> <chapter id="kcachegrind-concepts"> <title >Grundlegende Konzepte</title> <para >Dieses Kapitel erläutert einige in &kcachegrind; verwendete Konzepte und Begriffe aus der Bedienungsoberfläche. </para> <sect1 id="concepts-model"> <title >Das Datenmodell der Profildaten</title> <sect2> <title >Kosteneinheiten</title> <para >Kosten von Ereignistypen (wie L2-Misses) sind Kostenpunkten zugeordnet, was Elemente mit Bezugspunkten im Quelltext oder in Datenstrukturen eines gegebenen Programms sind. Kostenpunkte können nicht nur einfache Positionen im Quelltext oder in Daten sein, sondern auch Positions-Tupel. Ein Aufruf, zum Beispiel, hat eine Quelle und ein Ziel, und eine Datenadresse kann einen Datentyp und eine Adresse im Quelltext haben, an der er alloziert wird. </para> <para >&kcachegrind; sind die wie folgt genannten Kostenpunkte bekannt. Einfache Positionen: <variablelist ><varlistentry ><term >Instruktion</term > <listitem ><para > Eine Assembler-Instruktion an einer bestimmten Adresse.</para ></listitem > </varlistentry > <varlistentry > <term >Quelltextzeile einer Funktion</term > <listitem ><para > Alle Instruktionen, die der Compiler (über Debug-Informationen) einer Quelltextzeile zuordnet (Dateiname und Zeilennummer) und die im Kontext einer Funktion ausgeführt werden. Letzteres ist wichtig, da eine Zeile innerhalb einer Inline-Funktion im Kontext verschiedener Funktionen auftauchen kann. Instruktionen ohne Zuordnung erscheinen mit Zeilennummer 0 in Datei <filename >???</filename >. </para ></listitem > </varlistentry > <varlistentry > <term >Funktion</term > <listitem ><para > Alle Quelltextzeilen einer Funktion. Eine Funktion wird über ihren Namen und, sofern vorhanden, ihre Position in einem Binärobjekt angegeben. Letzteres ist wichtig, da jedes Binärobjekt eines Programms Funktionen mit demselben Namen enthalten kann (auf diese kann ⪚ mit <function >dlopen</function > oder <function >dlsym</function > zugegriffen werden; der Laufzeit-Linker löst Funktionen in verwendeten Binärobjekten in einer bestimmten Suchreihenfolge auf). Wenn ein Profiling-Werkzeug den Symbolnamen einer Funktion nicht bestimmen kann, ⪚ weil keine Debug-Informationen verfügbar sind, wird entweder die Adresse der zuerst ausgeführten Instruktion, oder <function >???</function > angegeben. </para ></listitem > </varlistentry > <varlistentry ><term >Binärobjekt</term > <listitem ><para > Alle Funktionen, die innerhalb der Grenzen eines gegebenen Binärobjekts liegen. Dies gilt für die primäre Programmdatei, sowie für Shared-Libraries. </para ></listitem > </varlistentry > <varlistentry > <term >Quelltextdatei</term > <listitem ><para > Alle Funktionen, deren erste Instruktion einer Zeile der gegebenen Quelltextdatei zugeordnet ist. </para ></listitem > </varlistentry > <varlistentry > <term >Klasse</term > <listitem ><para > Symbolnamen von Funktionen sind normalerweise hierarchisch in Namensräumen geordnet, ⪚ C++-Namensräume, oder Klassen in objektorientierten Sprachen; daher kann eine Klasse selbst Funktionen der Klasse und eingebetteter Klassen enthalten. </para ></listitem > </varlistentry > <varlistentry > <term >Profilabschnitt</term > <listitem ><para > Ein Zeitabschnitt eines Profiler-Durchlaufs mit einem gegebenen Thread-ID, Prozess-ID und ausgeführter Befehlszeile.</para ></listitem > </varlistentry > </variablelist > Wie Sie an der Liste erkennen können, definiert ein Satz Kostenpunkte oft einen neuen Kostenpunkt; daher entsteht eine Einrechnungshierarchie von Kostenpunkten, die durch die obige Beschreibung ersichtlich sein sollte. </para> <para >Positions-Tupel: <itemizedlist > <listitem ><para >Aufruf von Instruktionsadresse auf Zielfunktion.</para ></listitem > <listitem ><para >Aufruf von Quelltextzeile auf Zielfunktion.</para ></listitem > <listitem ><para >Aufruf von Quellfunktion auf Zielfunktion.</para ></listitem > <listitem ><para >(Un)bedingter Sprung von Quellinstruktion auf Zielinstruktion.</para ></listitem > <listitem ><para >(Un)bedingter Sprung von Quellzeile auf Zielzeile.</para ></listitem > </itemizedlist > Sprünge zwischen Funktionen werden nicht unterstützt, da diese in einem Aufrufgraphen nicht sinnvoll sind; daher müssen Konstruktionen wie Ausnahmen (Exceptions) und Long-Jumps in C so verändert werden, dass sie, sofern nötig, als Pop-Instruktion auf den Aufrufstapel ausgeführt werden. </para> </sect2> <sect2> <title >Ereignistypen</title> <para >In den Profildaten können weitere Ereignistypen angegeben werden, indem ihnen ein Name zugeordnet wird. Ihre Kosten bezogen auf einen Kostenpunkt ist ein 64-Bit-Integer. </para> <para >Ereignistypen, deren Kosten in einer Profildaten-Datei angegeben sind, heißen <quote >echte Ereignisse</quote >. Zusätzlich können Sie Formeln für Ereignistypen definieren, die aus echten Ereignissen errechnet werden. Diese heißen abgeleitete Ereignisse. </para> </sect2> </sect1> <sect1 id="concepts-state"> <title >Darstellungsstatus</title> <para >Der Darstellungsstatus eines &kcachegrind;-Fensters beinhaltet: <itemizedlist > <listitem ><para >den anzuzeigenden primären und sekundären Ereignistyp,</para ></listitem > <listitem ><para >die Funktionsgruppierung (für die <guilabel >Funktionsprofil</guilabel >-Liste und die Einfärbung der Elemente),</para ></listitem > <listitem ><para >die Abschnitte des Profils, die in die Darstellung eingehen</para ></listitem > <listitem ><para >ein aktiver Kostenpunkt (⪚ eine Funktion, die aus der Funktionsprofil-Ansicht ausgewählt wurde),</para ></listitem > <listitem ><para > ein ausgewählter Kostenpunkt.</para ></listitem > </itemizedlist > Dieser Status beeinflusst die Darstellung. </para> <para >Ansichten werden immer nur für einen Kostenpunkt (den aktiven) dargestellt. Ist eine Darstellung nicht angemessen für einen Kostenpunkt, wird sie ausgeblendet (⪚ wenn ein &ELF;-Objekt aus der Gruppenliste ausgewählt wird, sind Anmerkungen am Quelltext nicht sinnvoll). </para> <para >Zum Beispiel zeigt die Aufgerufene-Liste einer aktiven Funktion alle Funktionen, die auf der aktiven heraus aufgerufen wurden. Sie können eine dieser Funktionen markieren, ohne sie zu aktivieren. Wird der Aufruf-Graph daneben angezeigt, wird hier automatisch die gleiche Funktion ausgewählt. </para> </sect1> <sect1 id="concepts-guiparts"> <title >Bestandteile der Benutzeroberfläche</title> <sect2> <title >Navigationsbereich</title> <para >Docks sind Seitenfenster, die an jeder Seite des &kcachegrind;-Fensters angebracht werden können. Sie enthalten jeweils eine Liste mit Kostenpunkten in einer bestimmten Ordnung. <itemizedlist> <listitem ><para >Das <guilabel >Funktionsprofil</guilabel > ist eine Liste von Funktionen, in der die Inklusiv- und Exklusivkosten, die Anzahl der Aufrufe, der Name und die Position der Funktionen angezeigt werden. </para ></listitem> <listitem ><para> <guilabel >Übersicht der Profilabschnitte</guilabel> </para ></listitem> <listitem ><para> <guilabel >Aufrufstapel</guilabel> </para ></listitem> </itemizedlist> </para> </sect2> <sect2> <title >Ansichtsbereiche</title> <para >Der Anzeigebereich, gewöhnlich der rechte Bereich im &kcachegrind;-Hauptfenster, ist aus einem (Standard), oder mehreren Unterfenstern aufgebaut, die entweder waagerecht oder senkrecht angeordnet sind. Jedes Unterfenster enthält verschiedene Ansichten, die jeweils immer einen Kostenpunkt anzeigen. Der Name dieses Kostenpunkts wird oben im Unterfenster angezeigt. Sind mehrere Unterfenster vorhanden, ist immer nur eines von ihnen aktiv. Der Name des Kostenpunkts wird im aktiven Unterfenster fett dargestellt und bestimmt den aktiven Kostenpunkt im &kcachegrind;-Fenster. </para> </sect2> <sect2> <title >Bereiche eines Unterfensters</title> <para >Jedes Unterfenster kann bis zu vier Bereiche enthalten: oben, rechts, links und unten. Zudem kann jeder Bereich mehrere Ansichten enthalten. Der sichtbare Teil eines Bereichs wird über die Unterfensterleiste ausgewählt. Die Unterfensterleisten der oberen und rechten Bereiche befindet sich oben; die der linken und unteren Bereiche befinden sich unten. Sie können festlegen, welche Darstellungsart in welchem Bereich angezeigt wird, indem Sie das Kontextmenü des Unterfensters verwenden. </para> </sect2> <sect2> <title >Abgleich von Ansichten über ein ausgewähltes Element in einem Unterfenster</title> <para >Neben einem aktiven Element hat jedes Unterfenster ein ausgewähltes Element. Da die meisten Darstellungsarten mehrere Elemente anzeigen, wobei das aktive irgendwie zentriert wird, können Sie das gewählte Element ändern, indem Sie in der Ansicht navigieren (mit Mausklick oder der Tastatur). Ausgewählte Elemente werden hervorgehoben. Wenn Sie die Auswahl in einer Ansicht eines Unterfensters ändern, wird die Hervorhebung in allen anderen Ansichten ebenfalls geändert. </para> </sect2> <sect2> <title >Abgleich zwischen Unterfenstern</title> <para >Sind mehrere Unterfenster vorhanden, ändert eine Auswahländerung in einem Unterfenster eine Aktivitätsänderung im nächsten Unterfenster rechts oder unter dem ersten Unterfenster. Diese Verknüpfung ermöglicht eine schnelle Navigation in Aufruf-Graphen. </para> </sect2> <sect2> <title >Layouts</title> <para >Das Layout aller Unterfensteransichten eines Fensters kann gespeichert werden (siehe Menüpunkt <menuchoice ><guimenu >Ansicht</guimenu ><guisubmenu >Layout</guisubmenu ></menuchoice >). Nach dem Kopieren des aktuellen Layouts (<menuchoice ><shortcut ><keycombo action="simul" >&Ctrl; <keycap >+</keycap ></keycombo ></shortcut > <guimenu >Ansicht</guimenu > <guisubmenu >Layout</guisubmenu ><guimenuitem >Kopieren</guimenuitem > </menuchoice >) und Ändern einiger Größen oder Verschieben einer Darstellungsansicht in einen anderen Bereich einer Unterfensteransicht können Sie mit <keycombo action="simul" >&Ctrl;<keycap >Pfeil links</keycap ></keycombo > bzw. <keycombo action="simul" >&Ctrl;<keycap >Pfeil rechts</keycap ></keycombo > zwischen dem alten und dem neuen Layout umschalten. Die Layouts werden über &kcachegrind;-Sitzungen mit dem gleichen Profiler-Befehl hinweg gespeichert. Sie können die aktuellen Layouts als Voreinstellung für neue Sitzungen speichern, oder das Standard-Layout wiederherstellen. </para> </sect2> </sect1> <sect1 id="concepts-sidedocks"> <title >Navigationsbereich</title> <sect2> <title >Flaches Profil</title> <para >Das <guilabel >flache Profil</guilabel > enthält eine Gruppenliste und eine Funktionsliste. Die Gruppenliste zeigt alle Gruppen, in denen Kosten verursacht werden, abhängig vom gewählten Gruppentyp. Die Gruppenliste ist ausgeblendet, wenn die Gruppierung ausgeschaltet ist. </para> <para >Die Funktionsliste enthält die Funktionen der gewählten Gruppe (oder alle Funktionen, wenn die Gruppierung abgeschaltet ist), sortiert nach Spalten, ⪚ Inklusiv- oder Exklusivkosten. Die Anzahl der Elemente in der Liste ist begrenzt, und kann unter <menuchoice ><guimenu >Einstellungen</guimenu ><guimenuitem >&kcachegrind; einrichten ...</guimenuitem ></menuchoice > angepasst werden. </para> </sect2> <sect2> <title >Übersicht der Profilabschnitte</title> <para >Während eines Profiler-Durchlaufs können mehrere Profildaten-Dateien erzeugt werden, die alle zusammen in &kcachegrind; geladen werden können. Das Dock <guilabel >Übersicht der Profilabschnitte</guilabel > zeigt diese an, waagerecht angeordnet nach Erstellungszeit. Die Größen der Rechtecke sind proportional zu den Kosten der Abschnitte. Sie können einen oder mehrere Abschnitte auswählen um die Anzeige der Kosten in den anderen &kcachegrind;-Ansichten auf diese Abschnitte zu beschränken. </para> <para >Die Abschnitte sind weiter unterteilt in einen Partitions- und einen Inklusivkosten-Modus: <variablelist> <varlistentry> <term ><guilabel >Anzeigemodus für Details</guilabel ></term> <listitem ><para >Die Aufteilung der Dateien eines Profildaten-Abschnitts wird in Gruppen angezeigt, je nachdem, welcher Gruppentyp ausgewählt ist. Sind zum Beispiel &ELF;-Objektgruppen ausgewählt, sehen Sie farbige Rechtecke für jedes benutzte &ELF;-Objekt (Shared-Library oder Programmdatei), deren Größe durch die verursachten Kosten bestimmt wird. </para ></listitem> </varlistentry> <varlistentry> <term ><guilabel >Diagramm-Modus</guilabel ></term> <listitem ><para >Es wird ein Rechteck mit den Inklusivkosten der aktiven Funktion angezeigt. Dieses ist wiederum in die Inklusivkosten der aufgerufenen Funktionen unterteilt. </para ></listitem> </varlistentry> </variablelist> </para> </sect2> <sect2> <title >Aufrufstapel</title> <para >Dieser Aufrufstapel ist nicht echt sondern ein <quote >sehr wahrscheinliches</quote > Abbild. Er wird von der aktiven Funktion her aufgebaut und enthält alle Aufrufer und Aufgerufenen absteigend mit den höchsten Kosten oben. </para> <para >Die Spalten <guilabel >Kosten</guilabel > und <guilabel >Aufrufe</guilabel > zeigen die Kosten aller Aufrufe der Funktion eine Zeile höher. </para> </sect2> </sect1> <sect1 id="concepts-views"> <title >Ansichten</title> <sect2> <title >Ereignistyp</title> <para >Die <guilabel >Ereignistyp</guilabel >-Liste zeigt alle verfügbaren Kostentypen und die dazugehörigen Exklusiv- und Inklusivkosten der derzeit aktiven Funktion für den Ereignistyp. </para> <para >Wenn Sie einen Ereignistyp wählen, ändern Sie den Kostentyp, der überall in &kcachegrind; angezeigt wird. </para> </sect2> <sect2> <title >Aufruflisten</title> <para >Diese Listen zeigen Aufrufe auf und von der derzeit aktiven Funktion. <guilabel >Alle Aufrufer</guilabel > und <guilabel >Alle Aufgerufenen</guilabel > bedeutet, dass diese Funktionen in Richtung vom Aufrufer zum Aufgerufenen erreichbar sind, selbst wenn andere Funktionen dazwischen stehen. </para> <para >Die Ansicht von Aufruflisten enthält: <itemizedlist> <listitem ><para >Direkte <guilabel >Aufrufer</guilabel ></para ></listitem> <listitem ><para >Direkt <guilabel >Aufgerufene</guilabel ></para ></listitem> <listitem ><para ><guilabel >Alle Aufrufer</guilabel ></para ></listitem> <listitem ><para ><guilabel >Alle Aufgerufenen</guilabel ></para ></listitem> </itemizedlist> </para> </sect2> <sect2> <title >Karten</title> <para >Eine Baumstruktur-Darstellung des primären Ereignistyps, auf- oder abwärts in der Aufrufhierarchie. Jedes farbige Rechteck stellt eine Funktion dar; die Größe ist (abgesehen von zeichnerischen Ungenauigkeiten) proportional zu den verursachten Kosten, während die aktive Funktion ausgeführt wird. </para> <para >In der <guilabel >Aufruferkarte</guilabel > zeigt der Graph die eingebettete Hierarchie aller Aufrufer der aktiven Funktion; in der <guilabel >Aufrufkarte</guilabel > werden alle aufgerufenen Funktionen angezeigt. </para> <para >Einstellungen zum Erscheinungsbild finden Sie im Kontextmenü. Wählen Sie <guimenuitem >Unpassende Ränder nicht zeichnen</guimenuitem > um genaue Größen-Proportionen zu bekommen. Da dieser Modus sehr zeitintensiv sein kann, ist es ratsam, die maximale Verschachtelungstiefe zu begrenzen. <guilabel >Beste Teilungsrichtung pro Ebene</guilabel > bestimmt die Teilungsrichtung anhand des Seitenverhältnisses des übergeordneten Elements. <guilabel >Immer beste Teilungsrichtung</guilabel > entscheidet anhand des verbleibenden Platzes für jedes Geschwister. <guilabel >Proportionen ignorieren</guilabel > nutzt den Platz zuerst für die Funktionsbeschriftung. Beachten Sie, dass das Größenverhältnis stark abweichen kann. </para> <para >Tastatursteuerung ist mit der linken und rechten Pfeiltaste möglich, um die Geschwister zu durchlaufen; und mit den Tasten Pfeil hoch/runter, um Verschachtelungebenen hoch bzw. runter zu gehen. Die Eingabetaste aktiviert das aktuelle Element. </para> </sect2> <sect2> <title >Aufrufgraph</title> <para >Diese Ansicht zeigt den Aufrufgraph um die aktive Funktion herum an. Die angezeigten Kosten sind nur die Kosten, die bei der Ausführung der Funktion angefallen sind; &ie; die Kosten für <function >main()</function >, sofern angezeigt, sollten den Kosten der aktiven Funktion entsprechen, da diese ein Teil der Inklusivkosten von <function >main()</function > sind, die bei der Ausführung der aktiven Funktion angefallen sind. </para> <para >Für Zyklen wird ein blauer Pfeil angezeigt, der angibt, dass es sich nicht um einen echten Aufruf handelt; er wird nie ausgeführt, sondern nur zum richtigen Zeichnen benötigt. </para> <para >Ist der Graph größer als der Zeichenbereich, wird in einer Ecke eine Übersicht angezeigt. Es gibt ähnliche Darstellungen für die Aufruf-Baumansicht; die ausgewählte Funktion ist hervorgehoben. </para> </sect2> <sect2> <title >Code-Anmerkungen</title> <para >Die Quelltext/Assembler-Listen mit Anmerkungen zeigen die Quelltextzeilen bzw. disassemblierten Instruktionen der aktiven Funktion zusammen mit den (Exklusiv)-Kosten, die beim Ausführen der Quelltextzeile/Instruktion verursacht wurden. Im Falle eines Aufrufs werden Zeilen mit Details zum Aufruf in den Quelltext eingefügt: (Inklusiv)-Kosten innerhalb des Aufrufs, Anzahl der Aufrufe und Aufrufziel. </para> <para >Wählen Sie so eine Aufrufinformationslinie, um das Aufrufziel zu aktivieren. </para> </sect2> </sect1> </chapter> <chapter id="commands"> <title >Befehlsreferenz</title> <sect1 id="kcachegrind-mainwindow"> <title >Das Hauptfenster von &kcachegrind;</title> <sect2> <title >Das Menü <guimenu >Datei</guimenu ></title> <para> <variablelist> <varlistentry> <term ><menuchoice ><shortcut > <keycombo >&Ctrl;<keycap >N</keycap ></keycombo > </shortcut > <guimenu >Datei</guimenu > <guimenuitem >Neu</guimenuitem > </menuchoice ></term> <listitem ><para ><action >Öffnet ein leeres Hauptfenster, in das Sie Profildaten laden können.</action > Diese Aktion wird eigentlich nicht benötigt, da <menuchoice ><guimenu >Datei</guimenu > <guimenuitem >Öffnen ...</guimenuitem > </menuchoice > ein neues Hauptfenster öffnet, wenn im aktuellen Fenster bereits Daten angezeigt werden. </para ></listitem> </varlistentry> <varlistentry> <term ><menuchoice ><shortcut > <keycombo >&Ctrl;<keycap >O</keycap ></keycombo > </shortcut > <guimenu >Datei</guimenu > <guimenuitem >Öffnen ...</guimenuitem > </menuchoice ></term> <listitem> <para ><action >Öffnet den "Datei öffnen"-Dialog zur Auswahl der zu ladenden Profildaten-Datei.</action > Wenn im aktuellen Fenster bereits Daten angezeigt werden, wird ein neues Hauptfenster geöffnet. Zum Hinzufügen zusätzlicher Profildaten im aktuellen Fenster, verwenden Sie <menuchoice ><guimenu >Datei</guimenu > <guimenuitem >Hinzufügen ...</guimenuitem > </menuchoice >. </para> <para >Der Name von Profildaten-Dateien endet normalerweise auf <literal role="extension" ><replaceable >pid</replaceable >.<replaceable >part</replaceable >-<replaceable >threadID</replaceable ></literal >, wobei <replaceable >part</replaceable > und <replaceable >threadID</replaceable > optional sind. <replaceable >pid</replaceable > und <replaceable >part</replaceable > werden für mehrere Profildaten-Dateien eines einzelnen Programmdurchlaufs verwendet. Wenn Sie eine Datei mit der Erweiterung <literal role="extension" ><replaceable >pid</replaceable ></literal > öffnen, werden vorhandene Daten-Dateien desselben Durchlaufs mit zusätzlichen Erweiterungen automatisch geladen. </para> <informalexample ><para >Beispiel: Existieren die Profildaten-Dateien <filename >cachegrind.out.123</filename > und <filename >cachegrind.out.123.1</filename >, wird beim Laden der ersten Datei automatisch die zweite Datei mit geladen. </para ></informalexample ></listitem> </varlistentry> <varlistentry> <term ><menuchoice ><guimenu >Datei</guimenu > <guimenuitem >Hinzufügen ...</guimenuitem > </menuchoice ></term> <listitem ><para ><action >Fügt im aktuellen Fenster eine Profildaten-Datei hinzu.</action > Hiermit können Sie das Laden mehrerer Daten-Dateien in einem Hauptfenster erzwingen, obwohl diese nicht aus demselben Durchlauf stammen, also nicht den Namenskonventionen für Profildaten-Dateien entsprechen. Das ist vor allem zum Direktvergleich einsetzbar. </para ></listitem> </varlistentry> <varlistentry> <term ><menuchoice ><shortcut > <keycombo ><keycap >F5</keycap ></keycombo > </shortcut > <guimenu >Datei</guimenu ><guimenuitem >Neu laden</guimenuitem > </menuchoice ></term> <listitem ><para ><action >Profildaten neu laden.</action > Dies ist vor allem dann sinnvoll, wenn eine neue Profildaten-Datei für eine bereits geladene Anwendung erzeugt worden ist. </para ></listitem> </varlistentry> <varlistentry> <term ><menuchoice ><shortcut ><keycombo action="simul" >&Ctrl;<keycap >Q</keycap ></keycombo > </shortcut ><guimenu >Datei</guimenu ><guimenuitem >Beenden</guimenuitem > </menuchoice ></term> <listitem ><para ><action >Beendet</action > &kappname;</para ></listitem> </varlistentry> </variablelist> </para> </sect2> </sect1> </chapter> <chapter id="faq"> <title >Fragen und Antworten</title> &reporting.bugs; &updating.documentation; <qandaset id="faqlist"> <qandaentry> <question> <para >Wozu ist &kcachegrind; gut? </para> </question> <answer> <para >&kcachegrind; ist nützlich für die späte Software-Entwicklungs-Phase Profiling. Wenn man keine Anwendungen entwickelt, dann braucht man &kcachegrind; nicht. </para> </answer> </qandaentry> <qandaentry> <question> <para >Was ist der Unterschied zwischen <guilabel >Incl.</guilabel > und <guilabel >Self</guilabel >? </para> </question> <answer> <para >Dies sind Kosteneigenschaften für Funktionen hinsichtlich einiger Ereignistypen. Da sich Funktionen gegenseitig aufrufen können, ist es sinvoll, zwischen Kosten zu unterscheiden, die die Funktion selbst verursacht (<quote >Exklusivkosten</quote >) und solchen, die alle aufgerufenen Funktionen berücksichtigt (<quote >Inklusivkosten</quote >). </para> <para >Also werden Sie für <function >main()</function > immer Inklusivkosten von nahezu 100 % haben, wogegen die Exlusivkosten vernachlässigbar sind, wenn die eigentliche Arbeit in einer anderen Funktion erledigt wird. </para> </answer> </qandaentry> <qandaentry> <question> <para >Die Werkzeug- und Menüleiste ist bei mir sehr spartanisch. Ist das normal?</para> </question> <answer> <para >Ihre &kcachegrind;-Installation ist wahrscheinlich fehlerhaft. Es wird empfohlen, das Programm mit dem Installationspräfix-Pfad Ihrer systemweiten &kde;-Installation zu übersetzen, wie ⪚ <userinput ><command >configure <option >--prefix=<replaceable >/opt/kde4</replaceable ></option ></command >; <command >make install</command ></userinput >. Wenn Sie einen anderen Ordner, ⪚ <filename class="directory" >$<envar >HOME</envar >/kde</filename > wählen, müssen Sie die Umgebungsvariable <envar >KDEDIR</envar > auf diesen Ordner setzen, bevor Sie &kcachegrind; ausführen. </para> </answer> </qandaentry> <qandaentry> <question> <para >Wenn ich in der <guilabel >Aufrufgraph</guilabel >-Ansicht auf eine Funktion klicke, werden für <function >main()</function > die gleichen Kosten angezeigt, wie für die gewählte Funktion. Sollten diese nicht immer 100 % betragen? </para> </question> <answer> <para >Sie haben eine Funktion unterhalb von <function >main()</function > gewählt, die geringere Kosten als <function >main()</function > selbst hat. Für jede Funktion wird nur der Teil der Kosten angezeigt, der von der <emphasis >aktivierten</emphasis > Funktion verursacht wird. Daher können die Kosten für eine Funktion nie höher sein als die der aktivierten Funktion. </para> </answer> </qandaentry> </qandaset> </chapter> <glossary> <glossentry id="costentity"> <glossterm >Kostenpunkt</glossterm> <glossdef ><para >Abstraktes Element mit Bezug zu Stellen im Quelltext denen sich Ereigniszahlen zuordnen lassen. Kostenpunkte werden in den Größen Position im Quelltext (⪚ Zeile, Funktion), Position der Daten (⪚ aufgerufene Datentypen, Datenobjekt), Ort der Ausführung (⪚ Thread, Prozess) und Tupel oder Tripel der genannten Positionen (⪚ Aufrufe, Zugriff auf Objekte, aus dem Cache entfernte Daten) angegeben.</para ></glossdef> </glossentry> <glossentry id="eventcosts"> <glossterm >Ereigniskosten</glossterm> <glossdef ><para >Summe der Ereignisse eines Ereignistyps, der während der Ausführung aufgetreten ist und zu einem bestimmten Kostenpunkt gehört. Die Kosten werden dem Punkt zugeordnet.</para ></glossdef> </glossentry> <glossentry id="eventtype"> <glossterm >Ereignistyp</glossterm> <glossdef ><para >Art eines Ereignisses, dessen Kosten einem Kostenpunkt zugeordnet werden können. Es gibt echte und abgeleitete Ereignistypen.</para ></glossdef> </glossentry> <glossentry id="inheritedeventtype"> <glossterm >Abgeleiteter Ereignistyp</glossterm> <glossdef ><para >Virtueller Ereignistyp, der nur in Darstellungen angezeigt wird, die mit einer Formel aus einem echten Ereignistyp errechnet werden.</para ></glossdef> </glossentry> <glossentry id="profiledatafile"> <glossterm >Profildaten-Datei</glossterm> <glossdef ><para >Eine Datei mit Daten, die Messwerte eines Profil-Experiments (oder eines Abschnitts davon) enthält oder beim Nachverarbeiten von Profildaten erzeugt wurde. Die Datenmenge verhält normalerweise linear zur Größe des Quelltextes.</para ></glossdef> </glossentry> <glossentry id="profiledatapart"> <glossterm >Profildaten-Abschnitt</glossterm> <glossdef ><para >Daten aus einer Profildaten-Datei.</para ></glossdef> </glossentry> <glossentry id="profileexperiment"> <glossterm >Profil-Experiment</glossterm> <glossdef ><para >Ein Programmablauf, der von einem Profiling-Werkzeug überwacht wird und eine oder mehrere Profildaten-Dateien aus Abschnitten und/oder Threads des Ablaufs erzeugt.</para ></glossdef> </glossentry> <glossentry id="profileproject"> <glossterm >Profil-Projekt</glossterm> <glossdef ><para >Eine Konfiguration für Profil-Experimente, die für ein zu überwachendes Programm, vielleicht in mehreren Versionen, verwendet wird. Profildaten zu vergleichen, ist nur dann sinnvoll, wenn sie in Experimenten eines Profil-Projekts erzeugt wurden.</para ></glossdef> </glossentry> <glossentry id="profiling"> <glossterm >Profiling</glossterm> <glossdef ><para >Der Prozess des Sammelns statistischer Informationen über die Laufzeit-Eigenschaften eines Programmablaufs.</para ></glossdef> </glossentry> <glossentry id="realeventtype"> <glossterm >Echte Ereignistypen</glossterm> <glossdef ><para >Ereignistyp, der mit einem entsprechenden Werkzeug gemessen werden kann. Es ist ein Sensor für den gegebenen Ereignistyp erforderlich.</para ></glossdef> </glossentry> <glossentry id="trace"> <glossterm >Profildaten</glossterm> <glossdef ><para >Eine Abfolge zeitlich markierter Ereignisse, die beim Überwachen eines Programmablaufs aufgetreten sind. Die Datenmenge verhält sich normalerweise linear zu Laufzeit des Programms.</para ></glossdef> </glossentry> <glossentry id="tracepart"> <glossterm >Profildaten-Abschnitt</glossterm> <glosssee otherterm="profiledatapart"/> </glossentry> <glossentry id="tracing"> <glossterm >Tracing</glossterm> <glossdef ><para >Der Prozess des Überwachens eines Programmaufrufs. Dabei werden auftretende Ereignisse nach Zeitstempeln sortiert in eine Datei geschrieben, die Profildaten-Datei.</para ></glossdef> </glossentry> </glossary> <chapter id="credits"> <title >Danksagungen und Lizenz</title> <para >Dank an Julian Seward für seine einzigartige Anwendung &valgrind; und Nicholas Nethercote für den &cachegrind;-Zusatz. Ohne diese Programme würde &kcachegrind; nicht existieren. Viele Ideen für die Benutzeroberfläche stammen ebenfalls von ihnen. </para> <para >Danke für die vielen Fehlerberichte und Vorschläge von verschiedenen Benutzern. </para> <para >Übersetzung Thomas Reitelbach <email >tr@erdfunkstelle.de</email ></para > &underFDL; </chapter> <appendix id="installation"> <title >Installation</title> <sect1 id="getting-kcachegrind"> <title >Bezugsquellen von &kcachegrind;</title> <para >&kcachegrind; ist Teil des &kde;-Paketes &package;. Zusätzlich gibt es das Programm, &callgrind;, und weitere Dokumentation Sie auf der Webseite <ulink url="http://kcachegrind.sf.net" > http://kcachegrind.sf.net</ulink >. Dort gibt es weitere Installations- und Kompilierungshinweise. </para> </sect1> <sect1 id="requirements"> <title >Anforderungen</title> <para >Um &kcachegrind; benutzen zu können, benötigen Sie &kde; 4.x. Um die Ablaufprotokolle zu erzeugen, sind zusätzlich &cachegrind; oder &calltree;/&callgrind; erforderlich. </para> </sect1> <sect1 id="compilation"> <title >Kompilierung und Installation</title> &install.compile.documentation; </sect1> <sect1 id="configuration"> <title >Einrichtung</title> <para >Alle Einstellungsmöglichkeiten sind entweder im Einstellungsdialog oder in den Kontextmenüs der Graphen zu finden.</para> </sect1> </appendix> &documentation.index; </book>
