Hauptseminar Softwaretechnik. Profiler unter Linux

Transkript

1 Hauptseminar Softwaretechnik Profiler unter Linux Daniel Zinn 17. Januar 2004

2 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung Laufzeitbestimmung einzelner Module Laufzeit selbst messen Bibliotheks- und Systemaufrufe beobachten Alle Funktionsaufrufe beobachten Jede Zeile des Quelltextes analysieren Ein simulierter Prozessor Das gesamte System beobachten Das Speichermanagement Kommerzielle Tools Zusammenfassung Abbildungsverzeichnis 1 Ausgaben des time-befehls Quelltext des Beispiel-Programmes main ltrace analysiert main GProf call graph für main KProf: Hierarchische Darstellung von xdigger KProf: Aufrufgraph von xdigger (Ausschnitt) GCov: ergänzter Quelltext von main KCachegrind mit Quelltextbrowser und flachem Profil (xdigger) KCachegrind zeigt den Aufrufgraphen der main Funktion (xdigger) OProfile gibt Auskunft über xdigger MemProf analysiert das Programm main Valgrind analysiert das Programm main Valgrind deckt einen Speicherfehler auf Alleyoop analysiert das Programm main Valgui bei der Analyse von Speicherfehlern Profiler unter Linux

3 1 Einleitung 1 Einleitung Ein oft wichtiges Ziel in der Softwareentwicklung ist es, schnelle Produkte zu entwickeln. Die Wahl von schnellen Algorithmen spielt dabei eine große Rolle - leider sind sehr effiziente Algorithmen in der Regel sehr komplex. Im Gegensatz dazu ist man aber bestrebt die Komplexität einer Software so gering wie möglich zu halten. Der Grund hierfür sind einmal die meist höheren Entwicklungskosten und -zeiten, sowie ein erhöhter Aufwand in der Wartung. Darüberhinaus ist es umso schwieriger Korrektheit nachzuweisen je umfangreicher das Softwareprodukt ist. Obwohl moderne Programmiertechniken (Kapselung, Objektorientiertheit) es erlauben sehr komplexe Algorithmen als schon verifizierte Einheiten in das eigene Programm einzubauen, so bleibt das oben geschilderte Problem jedoch auf höherer Ebene erhalten. Oft ist es jedoch gar nicht nötig an allen Stellen des Programmes effizienteste Algorithmen einzusetzen. Der Grund hierfür ist, dass in den meisten Programmen ein großer Teil der Rechenzeit in nur wenigen Modulen verbraucht wird. So ist es möglich durch deren Optimierung die Software ausreichend zu beschleunigen. Mit Hilfe von sogenannten Profilern können zeitliche Messungen an Programmen und Modulen vorgenommen werden. Mit Ihnen kann man herausfinden, bei welchen Modulen sich Optimierungen lohnen. Profiler existieren für zahlreiche Betriebssysteme und für nochmehr Programmiersprachen: für Amiga, Windows, Linux - für.net, PHP, perl, Java und natürlich für C/C++. Profiler können weitaus mehr als nur herausfinden welche Module wieviel Zeit verbrauchen. Am Beispiel der C/C++ Programmierung unter Linux geben die folgenden Kapitel einen Überblick über grundlegende Profilingtechniken. Dies geschieht an Hand grundlegender Tools, welche unter der GNU Public License [3] frei zur Verfügung stehen. Der folgende Text ist also sowohl eine kurze Einführung zum Thema,,Profiling, als auch eine kleine Auflistung verfügbarer Tools für das Linux Betriebssystem zum Untersuchen von in C/C++ geschriebenen Programmen. Was sind Profiler? Wie schon in der Einleitung erwähnt dienen Profiler in erster Linie der Optimierung von Programmen. Profiler können folgende Fragen beantworten: Welche Module werden wirklich benötigt? Welche Anweisungen werden abgearbeitet? Wie oft werden die Anweisungen abgearbeitet? Welche Module verbrauchen die meiste Rechenzeit? In welchen Abschnitten wird die meiste Rechenzeit verbraucht? 3

4 2 Laufzeitbestimmung einzelner Module Darüberhinaus können Profiler das Speichermanagement analysieren und enthaltene Fehler aufzeigen. 2 Laufzeitbestimmung einzelner Module Theoretische Betrachtungen Natürlich ist es möglich die Laufzeiten durch theoretische Betrachtungen abzuschätzen. Bei vielen Basisalgorithmen sind solche Ergebnisse wohlbekannt und erleichtern die Auswahl der jeweiligen Algorithmen. Theoretisches Analysieren soll hier nicht das Thema sein, sondern wurde nur der Vollständigkeit halber erwähnt. 2.1 Laufzeit selbst messen Die wohl einfachste Möglichkeit ist eine Stoppuhr zu benutzen. Dies ist allerdings bei sehr kurzen (< 1 sec) oder langen Programmelaufzeiten (im Stundenbereich) sehr mühsam. Die,,eingebaute Stoppuhr von Linux ist das Kommando time: Wird ein Befehl mit vorangestelltem time gestartet, erhält man nach Programmende Informationen zur Laufzeit des Befehls. Abb. 1 zeigt Beispiele für die Ausgabe des time-befehls. (a) Main (b) Sleep Abbildung 1: Ausgaben des time-befehls Neben der Gesamtlaufzeit (real), wird auch die aktive Bearbeitungszeit im Nutzeradressraum (user) und die Zeit aufgelistet, die von Systemroutinen zur Abarbeitung benötigt wurde (system). Mehr Informationen kann man der Linux man page von time[4] entnehmen. Handelt es sich um selbst geschriebene Programme, so kann man die Funktion clock() benutzen; aus der Differenz eines Aufrufes vor und nach dem zu messenden Programmstück ist die vom Programm benötigte Zeit berechenbar. Weiterhin stellt Linux für jeden Prozeß noch drei Timer zur Verfügung: TIMER REAL Läuft in Echtzeit. ITIMER VIRTUAL Läuft nur, wenn der Prozeß selbst ausgeführt wird. 4 Profiler unter Linux

5 2.2 Bibliotheks- und Systemaufrufe beobachten ITIMER PROF Läuft wenn der Prozeß selbst ausgeführt wird, oder wenn das Betriebssystem im Auftrag des Prozesses handelt. Unter Zuhilfenahme der Systemfunktionen getitimer() und setitimer() können die oben genannten Timer genutzt werden, um Laufzeiten eigener Programmmodule zu ermitteln. Mehr Informationen sind unter der Linux man page für getitimer() [6] zu finden. 2.2 Bibliotheks- und Systemaufrufe beobachten In vielen Programmen wird von externen Bibliotheken reger Gebrauch gemacht. Oft wird sogar die Hauptarbeit von externen Bibliotheken oder dem Betriebssystem selbst erledigt. Mit Hilfe von ltrace[7] und strace[8] können alle Aufrufe in Bibliotheken bzw. in den Kernel selbst beobachtet werden. Auch bei diesen Kommandos sind keine besonderen Vorkehrungen nötig: Wie bei time wird der,,inspektionsprozess gestartet, indem man dem eigentlichen Befehl l- bzw. strace voranstellt. Mit der Option -c werden die Aufrufe gezählt und deren Bearbeitungszeiten addiert - die Ausgabe geschieht dann am Programmende. Dies ist am Beispiel eines kleinen Demonstrationsprogrammes - main - veranschaulicht. Abb. 2 zeigt den Quelltext, während Abb. 3 die Ausgabe von ltrace -cs main darstellt; bemerkenswert ist, dass sich durch die Messung die Ausführzeit des Programm von 0, 01 Sekunden auf 5 Sekunden erhöht hat. Was in der Physik gilt, trifft also auch hier zu - je genauer die Messergebnisse werden, desto stärker verfälschen sie den zu messenden Prozess. Dies macht sich gerade bei vielen kleinen Aufrufen bemerkbar: Bei mehrmaligem Ausführen des ltrace Profilings variieren die für sin, random, new und delete gemessenen Ausführungszeiten stark. Dennoch kann das Wissen über die Anzahl von Aufrufen bestimmter Routinen sehr hilfreich sein und Rückschlüsse auf das Laufzeitverhalten zulassen. 2.3 Alle Funktionsaufrufe beobachten Während mit s- und ltrace Funktionsaufrufe in Bibliotheken und Kernel beobachtet werden können, gibt es auch zahlreiche Möglichkeiten am eigenen Quelltext zu messen. Im GCC sind Mechanismen eingebaut, um Profiling zu ermöglichen: Wird beim Kompilieren und Linken die Option -pg angegeben, schreibt das fertige Programm während der Laufzeit statistische Daten in die Datei gmon.out. Sie kann mit Hilfe des GNU Profiler (GProf) analysiert werden 1. Gesammelte statistische Daten können auf drei verschiedene Weisen ausgegeben werden: flat profile zeigt, wieviel Zeit das Programm in welcher Funktion verbracht hat und wie oft diese Funktion aufgerufen wurde. call graph listet für jede Funktion auf, von wem sie wie oft aufgerufen wurde; weiterhin schätzt GProf hier ab, wieviel Zeit in den Subroutinen verbraucht wurde. Abb. 4 zeigt den Call Graph für das Programm main. 1 mit GProf können nur Programme untersucht werden, die mit dem GCC kompiliert wurden 5

6 2.3 Alle Funktionsaufrufe beobachten Abbildung 2: Quelltext des Beispiel-Programmes main Abbildung 3: ltrace analysiert main 6 Profiler unter Linux

7 2.3 Alle Funktionsaufrufe beobachten annotated source listing ist eine Kopie des Quelltextes, ergänzt durch die Anzahl der Aufrufe der jeweiligen Funktionen. Abbildung 4: GProf call graph für main Wie für viele Kommandozeilentools existiert auch für GProf ein graphisches Frontend - KProf. KProf bietet vier Sichten auf die statistischen Daten an: Die von GProf textuell ausgegebenen Informationen werden in den Registern für das flache und hierarchische Profil dargestellt. Natürlich kann man sämtliche Einträge nach Belieben sortieren - z.b. nach Anzahl der Aufrufe. Im Kontextmenü zu den jeweiligen Funktionen erscheinen Verweise auf Aufrufer und aufgerufene Funktionen. Neben diesen beiden klassischen Anordnungen können die Funktionen auch nach der Objekthierarchie innerhalb des Programmes sortiert werden. Darüber hinaus kann KProf die Aufrufhierarchie selbst grafisch darstellen - oder als Datei in den Graphen-Formaten für VCG bzw. GraphViz abspeichern. Eine genauere Beschreibung, was mit diesen Formaten alles möglich ist, würde den Rahmen hier sprengen; Eine kleine Analyse des Programmes xdigger mit KProf zusammen mit einem Auschnitt des Aufrufgraphen zeigen Abb. 5 und Abb. 6. Im Register Method View ist eine detaillierte Beschreibung der einzelnen Methoden verfügbar: die Navigation zu aufgerufenen und aufrufenden Funktionen ist aufgrund der guten Verlinkung sehr angenehm. 7

8 2.3 Alle Funktionsaufrufe beobachten Abbildung 5: KProf: Hierarchische Darstellung von xdigger Abbildung 6: KProf: Aufrufgraph von xdigger (Ausschnitt) 8 Profiler unter Linux

9 2.4 Jede Zeile des Quelltextes analysieren 2.4 Jede Zeile des Quelltextes analysieren Im Gegensatz zu GProf, welches das Programm auf der Basis von Funktionsaufrufen analysiert, bietet GCov Informationen über jede Zeile des Quelltextes. Wie bei GProf, ist es nötig das zu inspizierende Programm mit speziellen Optionen zu übersetzen 2. Die zu benutzenden Optionen sind -fprofile-arcs und -ftest-coverage. Während das ausführbare Programm erzeugt wird, werden Dateien mit den Endungen bb und bbg angelegt. Diese enthalten,,im Wesentlichen einen Flußgraphen des Programms, welcher zur Ausführung benötigt wird. Die eigentlichen statistischen Daten werden in.da Dateien erzeugt, und bei mehrmaliger Ausführung aufsummiert. So können Daten über verschiedene Testfälle hinweg akkumuliert werden, was in Bezug auf Anweisungsüberdeckungstests sehr hilfreich ist. Weiterhin können so Informationen über einen langen Zeitraum gesammelt werden, um das Durschnittsverhalten der Software besser einschätzen zu können. Der Befehl GCov erzeugt aus den statistischen Daten kommentierte Quelltexte: vor jeder Codezeile steht, wie oft diese ausgeführt wurde. Durch entsprechende Parameter ist es auch möglich, sich für alle Verzweigungen im Programm die Wahrscheinlichkeiten für jeden Zweig anzeigen zu lassen. Abb. 7 zeigt den mit Befehlshäufigkeiten ergänzten Quelltext von main. Abbildung 7: GCov: ergänzter Quelltext von main 2.5 Ein simulierter Prozessor Bei den meisten bisher vorgestellten Profilingtechniken ist es nötig, sein Programm mit speziellen Kompileroptionen zu übersetzen. Ein anderes Profilingtool, Valgrind, geht einen anderen Weg: anstatt zusätzlichen Code in die Programme einzubauen, simuliert Valgrind einen kompletten Prozessor mit Speicher. Die Valgrind-Suite ist modular aufgebaut - zu dem Core, der die Emulation des Prozessors übernimmt, können verschiedene 2 mit GCov können nur Programme untersucht werden, die mit dem GCC kompiliert wurden 9

10 2.6 Das gesamte System beobachten,,skins benutzt werden. Die wichtigsten Skins sind Cachegrind, Calltree und Memcheck: Cachegrind Cachegrind ist ein Cache Profiler, d.h. dieser Skin simuliert zusätzlich zum Programmkern von Valgrind die I1, D1 and L2 Caches. Er kann so Cache Misses, Speicherzugriffe und Instruktionen des Programmes basierend auf Quelltextzeile, Funktion oder auch global für das gesamte Programm darstellen. Cachegrind findet vor dem Start die Konfiguration der aktuellen CPU heraus und kann so sein Prozessormodell auf den momentanen PC anpassen. Calltree Calltree erweitert den Cachegrind Skin um Informationen, welche Funktionen welche anderen aufgerufen haben. Somit sind mit Calltree neben den flachen Profilen der Funktionen auch hierarchische Darstellungen möglich. Mit Hilfe des KDE Programmes KCachegrind können die mit Calltree gesammelten Informationen in einem graphischen Nutzerinterface sehr benutzerfreundlich analysiert werden. Es existiert die Möglickeit alle Funktionen nach Anzahl der Instruktionen, nach lesendem bzw. schreibendem Zugriff sowie nach der Anzahl der Cache Verfehlungen für L1 und L2 Cache zu sortieren. Natürlich kann man auch nach der Anzahl der Funktionsaufrufe selbst sortieren. Sehr gut gelungen ist meiner Meinung nach auch der Quelltextbrowser (siehe Abb. 8). Bereichert durch Profilinginformationen kann man durch die gute Verlinkung gut navigieren. Am beeindruckendsten fand ich die graphische Visualisierung der Aufrufhierarchie, welche durch Kontextmenüs vielfältig angepasst werden kann: Abb. 9 zeigt den Aufrufgraphen der main Funktion des Programmes xdigger. Die relative Größenverteilung entspricht den Anzahl der CPU Instruktionen 3, welche von den Funktionen benötigt wurde. Memcheck Dieser Skin ist für Speicher Profiling nützlich, und wird deshalb in Abschnitt 3 näher beschrieben. Die Abarbeitungszeit des Programms verlangsamt sich laut Dokumentation [12] etwa um den Faktor 50 - dies beeinflußt aber wegen der Simulation des Programmes nicht die statistischen Ergebnisse. 2.6 Das gesamte System beobachten Will man neben dem eigenen Programm auch das gesamte System unter die Lupe nehmen, bietet sich OProfile an. OProfile ist ein systemweiter Profiler für Linux Systeme. 3 oder einem der anderen Aspekte, nach denen sortiert werden kann 10 Profiler unter Linux

11 2.6 Das gesamte System beobachten Abbildung 8: KCachegrind mit Quelltextbrowser und flachem Profil (xdigger) Abbildung 9: KCachegrind zeigt den Aufrufgraphen der main Funktion (xdigger) 11

12 3 Das Speichermanagement Er nutzt die internen Counter moderner CPUs, um Profiling Daten zu sammeln 4. Er kann mit wenig Overhead Hardware und Software, Interrupthandler, Kernel Module, den Kernel selbst, Shared Libraries und Anwendungen untersuchen. OProfile besteht aus einem Kernel Modul, einem Daemon, der die Daten sammelt, und verschiedenen Werkzeugen zum Auswerten der gesammelten Daten. Neben einer Auflistung aller Prozesse und Libraries (nach Laufzeit sortiert), kann man sich auch innerhalb eines beliebigen Programmes die Funktionen nach Laufzeit sortiert anzeigen lassen 5. Abb. 10 zeigt die Ausgabe, wenn man über xdigger Auskunft haben möchte. Abbildung 10: OProfile gibt Auskunft über xdigger OProfile gehört nicht zu den Standard Paketen der Debian Linux Distribution 6, und muß deshalb selbst kompiliert werden, was aber durch den autoconf-mechanismus mittels./configure und make ohne Probleme durchführbar ist 7. 3 Das Speichermanagement Profiler sind auch in der Lage Fehler beim Speichermanagement aufzudecken. Im Gegensatz zu den Maßnahmen im ersten Kapitel, welche sich vorrangig um Geschwindigkeitsoptimierung kümmern, möchte ich nun Programme vorstellen, die helfen echte Programmierfehler aufzudecken. Fehler bei der Speicherbenutzung können zu sogenannten,,segmentation Faults führen 8. Dies ist der Fall, wenn ein Prozess versucht auf Speicherbereiche zuzugreifen, die nicht für ihn reserviert wurden. Moderne CPUs überprüfen bei 4 Aus diesem Grund darf der,,enhanced Real Time Clock Support nicht im Kernel aktiviert sein oder als Modul (rtc) geladen worden sein, wenn man OProfile benutzen will. 5 Natürlich kann auch OProfile nur dann Funktionennamen auflösen, wenn die zugehörigen Binaries Debuginformationen enthalten, also mit -g kompiliert wurden. 6 auch nicht im sid Zweig, Stand In der 2.6er Serie des Linux Kernels ist OProfile schon integriert; das Kernel Modul kann so einfach hinzugeladen werden. 8 oder Bluescreens in Windows-verwandten Betriebssystemen 12 Profiler unter Linux

13 3 Das Speichermanagement jedem Zugriff auf den Speicher, ob der angeforderte Bereich dem jeweiligen Prozeß zugeordnet ist. Dies schützt Programme gegenseitig,,voreinander. Weitere,,Speicher-Fehler bei der Programmierung sind zum Beispiel: Benutzen von nichtinitialisierten Speicherbereichen Lesen oder Schreiben von Speicher, nachdem dieser freigegeben wurde Lesen oder Schreiben über die Grenzen eines mit malloc reservierten Bereiches hinweg Lesen und Beschreiben von falschen Bereichen auf dem Stack Sogenannte,,Memory Leaks - wenn alle Zeiger auf dynamischen Speicherplatz gelöscht werden Falsche Kombinationen beim Benutzen von malloc, new und new [] mit free, delete und delete [] Überlappende src und dst Zeiger bei der Benutzung von memcpy() oder verwandten Funktionen und noch vieles mehr... Im folgenden möchte ich auf ein paar Tools eingehen, die helfen solche Probleme zu finden. Memory Leaks Memory Leaks entstehen, wenn alle Referenzen auf dynamisch reservierten Speicher verloren gehen oder überschrieben werden; dann ist es nämlich nicht mehr möglich auf diesen Bereich zuzugreifen oder ihn wieder frei zu geben. In Sprachen, wie C oder C++, die keine Garbage Collection besitzen, wächst so der vom Programm benutzte Speicher immer weiter an. Die Folge davon ist, dass das Betriebssystem verstärkt ausswappen muß - dies verlangsamt das betreffende und alle anderen Programme. Im schlimmsten Fall kann der Swapbereich vollaufen, und das Betriebssystem ist gezwungen Prozesse zu killen 9. top Der wohl einfachste Weg herauszufinden, ob ein Programm,,undichte Stellen besitzt, ist es während der Abarbeitung mittels top zu beobachten. Top listet alle Prozesse auf, und sortiert diese auf Wunsch (drücken von M) absteigend nach dem benutzten Speicher. 9 Was z.b. im Falle von Linux nicht unbedingt das verursachende Programm sein muß. 13

14 3 Das Speichermanagement MemProf Detailliertere Informationen bietet MemProf, eine grafische Gnome Anwendung. Mem- Prof kann den Speicher durchsuchen und dynamisch reservierte Blöcke finden, auf die nirgends mehr referenziert wird. Zusätzlich kann man sich auflisten lassen, welche Funktionen wieviel Speicher reserviert haben. Es ist nicht nötig, das zu inspizierende Programm mit speziellen Optionen zu kompilieren, da MemProf die Routinen zur Speicherbereitstellung durch Überladen der C Funktionen überschreibt 10. Abbildung 11: MemProf analysiert das Programm main Abb. 11 zeigt wie MemProf main analysiert; im Unterschied zu den bisher dargestellten Tools findet die Analyse zeitgleich mit der Abarbeitung des Programmes statt - der Balken bewegt sich also während das Programm abgearbeitet wird. Die drei verschiedenen Farben haben folgende Beutung: Gelb Reservierter Speicherbereich Blau Reservierter Bereich, der dann freigegeben wurde (,,high-warter-mark ) Rot Verweister Speicherbereich (erscheint nach Drücken der,,leaks Taste) Wie zu erkennen ist, existieren in dem Programm main verweiste Speicherbereiche. Hier ist es noch einfach, sie im Quelltext zu finden. Valgrind mit Memcheck Skin Der Memcheck-Skin von Valgrind eignet sich sehr gut zum Aufspüren von Speicherfehlern. Alle auf Seite 13 genannten Fehler werden von Memcheck entdeckt. Aufgerufen wird der Memory Profiler mit dem Befehl Valgrind vor dem zu testenden Programm. Dabei können durch verschiedene Parameter diverse Einstellungen getätigt werden. So z.b. veranlasst leak-check=yes Valgrind nach dem Beenden das Programmes nach Memory Leaks zu suchen. Die Option gdb-attach=yes startet den GNU Debugger nachdem ein Fehler entdeckt wurde. 10 Wie immer ermöglichen Debugoptionen (-g) Funktionsnamen aufzulösen. 14 Profiler unter Linux

15 3 Das Speichermanagement Abb. 12 zeigt die Ausgabe von Valgrind leak-check=yes nach dem Testen des,,undichten main Beispiels. Abbildung 12: Valgrind analysiert das Programm main Als letztes Beispiel möchte ich noch das Programm StringTest mit Valgrind analysieren. Es zeigt an wenigen Zeilen Quelltext, wie schwer es ist Speicherfehler zu entdecken; hinzukommt, dass der Fehler bei diesem kleinen Programm noch nicht einmal einen Absturz verursacht - es läuft anscheinend fehlerfrei. Genau solche Fehler sind es, die durch normales Debuggen sehr schwer zu finden sind und oft mysteriöse, nicht reproduzierbare Programmabstürze zur Folge haben. Der kurze Quelltext ist zusammen mit einem Ausschnitt der Analyse von Valgrind in Abb. 13 zu sehen: Der Speicherbereich der bei ptr für den String reserviert wird, ist um 1 Byte zu kurz 11. Wird nun der String an der Adresse ptr herausgeschrieben, liest der Prozessor eine nicht reservierte Speicherzelle; hier steht wahrscheinlich eine 0, sodass die Ausgabe,,Hello World scheinbar fehlerfrei auf dem Bildschirm erscheint. Auch kommt es zu keinem Segmentation fault, da Speicher durch das Betriebssystem nur seitenweise an Prozesse gegeben wird und die Schutzmechanismen auf der Granularität von Seiten und nicht einzelner Bytes verwirklicht sind. Als graphische Frontends für den Memcheck-Skin kann man Alleyoop [14] oder Valgui benutzen. 11 Die dreizehn Byte Speicherbedarf für den String ergeben sich aus zwölf Byte Buchstaben und der abschließenden 0 für C-Strings. 15

16 3 Das Speichermanagement (a) Quelltext (b) Analyse von Valgrind Abbildung 13: Valgrind deckt einen Speicherfehler auf Alleyoop stellt die Ergebnisse von Valgrind in einem Baum übersichtlicher dar; bei jedem gefundenen Memory Leak erscheinen die verursachenden Quelltextzeilen in der Baumansicht. Durch Doppelklicken kann ein Editor die entsprechende Datei öffnen und automatisch an die betreffende Quelltextzeile springen. Abb. 14 zeigt die Analyse des Programmes main. Abbildung 14: Alleyoop analysiert das Programm main Valgui ist nur als CVS Version erhältlich, und ließ sich erst nach kleineren Änderungen im Quelltext kompilieren 12. Der Funktionsumfang hingegen ist umfangreicher als der von 12 Benutzte QT-Version: 3.2.3; GCC Version Profiler unter Linux

17 4 Kommerzielle Tools Alleyoop: Einstellungen für Pfade der Quelldateien, zahlreiche Filtermöglichkeiten und Quelltextvorschau sind implementiert. Genauere Informationen sind auf der (recht rudimentären) Webpage von Valgui [15] verfügbar. Abb. 15 zeigt Valgui mit zwei Sichten auf dasselbe Dokument. Während die linke Seite gänzlich ungefiltert ist, ist bei der gefiltereten Ausgabe rechts auch ein Teil des Quellcodes vorhanden. Abbildung 15: Valgui bei der Analyse von Speicherfehlern 4 Kommerzielle Tools VTune Neben den hier vorgestellten freien Tools gibt es natürlich noch kommerzielle Produkte. Intel vertreibt das Produkt VTune, welches seit 2003 auch als Linux Version vorliegt. VTune für Linux benutzt, wie OProfile die Profiling Mechanismen moderner CPUs. Intel bietet eine 7-tägige Testversion des Produktes an - Die Installation der Linux Version erfolgt durch ein in kompilierter Form ausgeliefertes Installationsprogramm. Dies kann nur mit root-rechten ausgeführt werden, was mich davon abgehalten hat, das Programm weiter zu testen. 17

18 4 Kommerzielle Tools Rational Purify Plus Das von IBM angebotene Tool Rational Purify Plus erstellt Zeit- und Performance profile von Programmen und kann Memory Leaks aufspüren. Die in der Dokumentation vorgestellte Funktionalität und die gezeigte grafische Oberfläche sind sehr umfangreich. Auch IBM bietet eine 7-tägige Testversion an. Das Programm lies sich leicht installieren (was diesmal ohne Supernutzer-Rechte möglich war). Beim Ausführen der Testbeispiele erschien auf meinem System 13 die Fehlermeldung: ld.so: Incorrectly built binary which accesses errno or h errno directly. ld.so: See /usr/share/doc/libc6/faq.gz. Nach mehreren Warnungen hat Pruify schließlich abgebrochen. 13 GNU Debian Sid, er Kernel 18 Profiler unter Linux

19 5 Zusammenfassung 5 Zusammenfassung Hier die,,vorzüge und,,schwächen der vorgestellten Profilingtools: Programm Zeit messen Aufrufe zählen Speicher debuggen GUI Besonderheiten time l/strace GProf genaue Gesamtlaufzeit für das gesamte Programm Laufzeit für alle Funktionen - - nicht nötig System- und Bibliotheksfunktionen System- und Bibliotheksfunktionen alle Funktionen, zeigt Aufrufhierarchie KProf GCov - alle Befehle - - Valgrind Simulation aller Befehle, Bibliotheken und Systemaufrufe MemProf - - OProfile VTune, Rational Prurify alle Befehle Alle Funktionen, Bibliotheksund Systemaufrufe Alle Funktionen, Bibliotheksund Systemaufrufe zeigt Memory Leaks - - Alle Funktionen, Bibliotheksund Systemaufrufe Alle Funktionen, Bibliotheksund Systemaufrufe Viele Speicherfehler zeigt Vielzahl von Speicherfehlern KCachegrind, Alleyoop, Valgui ist GUI enthält umfangreiche GUIs keine Anforderungen an Programm keine Anforderungen an Programm Programm muß mit pg übersetzt werden Programm muß mit speziellen Optionen neu übersetzt werden Simulation einer CPU; Programm muß shared Libraries benutzen; sehr langsam zeigt Speicherverbrauch dynamisch während der Laufzeit benutzt Kernel Modul, profiled alle laufenden Prozesse eines Systems kommerzielle Tools 19

20 Index Index Alleyoop, Cachegrind, 10 Calltree, 10 clock(), 4 GCov, 9 getitimer(), 5 GProf, 5, 7, 9 KCachegrind, 10, 11 KProf, 7, 8 ltrace, 5, 6 Memcheck, 10, 14, 15 MemProf, 14 OProfile, 10, 12, 17 Rational Purify Plus, 18 setitimer(), 5 strace, 5 time, 4, 5 top, 13 Valgrind, 9, 10, Valgui, VTune, Profiler unter Linux

21 Literatur und Infos Literatur und Infos [1] Stephan Siemen: Programme beschleunigen mit Profilern und Memory-Debuggern; Linux-Magazin Okt [2] Günther Röhrich: Programmieren mit Linux; 2000 Linux-Magazin März 2000 [3] Gnu Public License, [4] Linux man pages, Sektion 1: time [5] Linux man pages, Sektion 3: clock [6] Linux man pages, Sektion 2: getitimer [7] Linux man pages, Sektion 1: ltrace [8] Linux man pages, Sektion 1: strace [9] Linux man pages, Sektion 1: gprof [10] Linux man pages, Sektion 1: gcov [11] KProf: [12] Valgrind, mit Skins: [13] KCachegrind und Calltree: [14] Alleyoop: [15] Valgui: [16] OProfile: [17] MemProf: [18] Rational Purify Plus: [19] VTune: 21