Der Pure-Profiler - Time is money
Bislang gab es auf dem ATARI außer dem relativ unkomfortablen und langsamen GNU-C-System mit prof- und gprof-, dem time-Kommando oder gar dem Messen per Stoppuhr keine Möglichkeit, eigene Programme schnell und effizient nach Engpässen im Laufzeitverhalten zu untersuchen. Diese Lücke versucht der Pure Profiler zu schließen.
Der Pure Profiler findet seinen Einsatz dann, wenn Programme zu langsam laufen und hilft bei der Suche nach den dafür verantwortlichen Programmteilen. Diese lassen sich schnell ausfindig machen, so daß man an den geschwindigkeitsbestimmenden Stellen, sofern möglich, effizientere Algorithmen einsetzen kann.
Dabei ist das Ziel weniger eine einfache Optimierung als vielmehr, Schwachpunkte herauszufinden, die einer substantiellen, algorithmischen Verbesserung bedürfen. Um ein Beispiel zu nennen: es hilft wenig, einen prinzipiell langsamen Bubblesort zu optimieren, und sei es auch in Assembler, wenn die verwendete Datenmenge einen Sortieralgorithmus wie Quicksort verlangt, dessen Ausführungszeit in einer anderen, günstigeren Größenordnung liegt.
Durch Einsatz des Profilers kann man nun aber nachvollziehen, an welchen Stellen solche Verbesserungen überhaupt sinnvoll sind. Schließlich lohnt sich, um beim Beispiel zu bleiben, der Einsatz eines Quicksort nicht, wenn nur wenige Male eine kleine Datenmenge sortiert werden soll. Die Optimierung soll ja nicht die Entwicklung behindern, sondern wertvolle Entwicklungszeit einsparen, so daß man sich auf die relevanten Teile konzentrieren kann.
Systemumgebung
Die Installation beschränkt sich auf das Kopieren der Diskette in einen beliebigen Ordner auf Festplatte. Besondere Ansprüche an die Rechnerausstattung werden nicht gestellt, der Profiler läuft in den unterschiedlichsten Auflösungen, Farbtiefen, und Rechnern, wobei der Falcon030 allerdings nicht selbst getestet werden konnte.
Als Entwicklungssysteme eignen sich zur Zusammenarbeit mit dem Profiler am besten die C- und Pascal-Compiler sowie Assembler aus gleichem Hause, da mit ihren aktuellen Versionen eine Untersuchung auf Quelltextebene möglich ist. Außer dem Neuübersetzen mit Debug-Informationen, zum Debuggen sowieso notwendig, ist nichts weiter zu tun. Aber da der Profiler auch mit dem DRI-Symbolformat zurechtkommt, lassen sich mit GFA BASIC, TurboAss und sogar mit GNU C übersetzte Programme auf symbolischer Ebene untersuchen. Lattice C hingegen eignet sich nicht. Bei Programmen, die über keine Symbolinformation verfügen, kann ein Profile über die Betriebssystemroutinen erfolgen.
Dadurch, daß der Profiler eine eigene, vom GEM unabhängige, aber sehr ähnliche Oberfläche besitzt, lassen sich auch GEM-Programme „profilen“ und, wie im Debugger, Breakpoints setzen und durch das Programm tracen. Die zeitliche Auflösung läßt sich bis auf 0.1 ms einstellen, was eine zwar spürbare, aber nicht hinderliche Verlangsamung des Programmablaufs bewirkt. Und je höher die Auflösung, desto genauer die Ergebnisse. Arbeitet man mit Pure C oder Pure Pascal, läßt sich zu jeder Funktion auf Tastendruck der zugehörige Quelltext einblenden und bis auf Assembler-Ebene hinunter darstellen.
Effizienz
Sehr hilfreich ist beim Profiling die Unterscheidung zwischen eigenen und Betriebssystemfunktionen, bei denen auch die des MiNT (Basis des MultiTOS) berücksichtigt werden. Optional können nicht im Quelltext vorliegende Funktionen zu einem Punkt Bibliotheksfunktionen zusammengefaßt werden, was die Übersichtlichkeit noch einmal steigert.
Wird der Großteil der Ausführungszeit eines Programmes z.B. im Betriebssystem bei Plattenoperationen benötigt, hilft eine Anpassung des eigenen Codes in der Regel wenig, es sei denn, sie dient dazu, die Anzahl der Plattenzugriffe zu verringern. Solche Engpässe sind mit dem Profiler in kürzester Zeit aufgedeckt.
Unterschiede zu I/O-Funktionen, wie dem Warten auf einen Tastendruck, werden dabei allerdings nicht gemacht, so daß einem der direkte Vergleich der Ausführungszeiten der einzelnen Systemteile mitunter etwas schwer gemacht wird. Hilfreich wäre hier, einzelne Funktionen ausblenden und dies als Konfiguration zum ausgeführten Programm speichern zu können, da solche Dinge vom Fluß des jeweiligen Programmes abhängen und nicht generell festzulegen sind. Ein bißchen helfen die Breakpoints darüber hinweg, mit denen man zwar das Profiling auf einzelne Programmteile einschränken kann, die jedoch ebenfalls nicht gespeichert werden können. Zumindest funktionsweise wäre dies nützlich.
Das Profil des Programmes wird in flacher Form dargestellt, d.h. daß jede Funktion, gleich ihrer Stellung im Programmfluß, für sich bewertet wird, ohne daß die Zeiten für daraus wiederum aufgerufene Programmteile mit einfließen. Das hat den Vorteil, daß auf einen Blick die zeitintensivsten Funktionen erkennbar sind. Wessen Monitor genug Platz bietet, kann sich dies sogar mit Balken anzeigen lassen. Nachteilig, und insgesamt der größte Schwachpunkt der jetzigen Profiler-Version, ist jedoch eben das Fehlen eines hierarchischen Profils, das die gesamte in einer Aufrufkette benötigte Zeit erfaßt. Es lassen sich zwar Aufrufketten anzeigen, doch fehlen dort Informationen zur Ausführungszeit.
Unter Nutzung der Breakpoints läßt sich aber auch diese Schwäche mildern. Keine direkte Unterstützung findet man allerdings bei der Ermittlung des durchschnittlichen Zeitbedarfes einer Funktion, da der Profiler grundsätzlich die Gesamtausführungszeiten erfaßt. Allerdings wird diese Art des Profilings seltener benötigt.
Effektivität
Doch nicht nur bei der Frage nach der Effizienz, also „wie gut ist der eingesetzte Algorithmus?", sondern auch bei der nach der Effektivität, „macht das Programm, was es soll?“, läßt sich der Profiler verwenden. Das Stichwort dazu lautet „Code Coverage“ und es meint die Kennzeichnung all der Stellen im Programm, die tatsächlich durchlaufen werden. In fett dargestellter Schrift werden diese Teile sehr übersichtlich dargestellt. Da bei einem Programmlauf nicht unbedingt sämtliche Funktionen aufgerufen werden, besteht die Möglichkeit des ergänzenden Code Coverages, das sich die bereits durchlaufenen Codebereiche vergangener Programmläufe merkt.
Der Sinn des Code Coverages liegt darin, unbenutzte Codeteile aufzuspüren, die möglicherweise aufgrund von Programmierfehlern nie ausgeführt werden. In einem eigenen IO-Fenster werden außerdem sämtliche Dateioperationen sowie dabei eventuell aufgetretene Fehler mitprotokolliert. Insgesamt stellen diese Funktionen somit eine gute Ergänzung zum Debugger auf höherer logischer Ebene dar.
Darstellung
Zunächst einmal lassen sich die Ergebnisse des Profilers formatiert in eine ASCII-Datei schreiben, wenngleich dies in der vorliegenden Version bisweilen Probleme bereitete. Die Bildschirmdarstellung ist gelungen, und es lassen sich hervorragend einfach die Ebenen, vom Gesamtprogramm bis hinunter zur Funktion oder gar einer einzelnen Quelltext- oder Assembler-Zeile, durchlaufen. Sowohl per Tastatur als auch mit der Maus, ebenso die Dialoge. Zur übersichtlichen Darstellung trägt auch bei, daß sich für die einzelnen Bereiche getrennte Fenster öffnen lassen. Daß auf kleinen Bildschirmen dennoch schnell die Übersicht verlorengeht, liegt nur daran, daß der Profiler die Texte ausschließlich im 8*16-Systemzeichensatz darstellt. Unverständlich. wenn man bedenkt, daß das Programm ansonsten mit VDI-Font (siehe Kasten) tadellos zurechtkommt. Der Einsatz von VDI-Font kann Nichtgroßbildschirmbesitzern beim Betrieb des Profilers daher nur empfohlen werden.
Insgesamt liegen sowohl Aufbereitung der Informationen als auch Komfort um eine Größenordnung über den mir bekannten prof, gprof und tcov auf (meist) UNIX-Systemen. Vergleichsergebnisse auf anderen Rechnertypen bestätigen, im Rahmen unterschiedlicher Systeme, die mit dem Pure Profiler ermittelten Ergebnisse.
Einige technische Schwächen sind derzeit noch vorhanden: so läßt sich der Profiler zwar unter MultiTOS starten, stürzt aber umgehend ab. Auch lassen sich keine Programme profilen, deren Quellen sich auf einem alternativen Dateisystem befinden (z.B. Minix-Dateisystem), und sehr selten verweigert der Profiler ein Programm gänzlich. Unter MiNT hingegen läuft er sehr stabil, wie natürlich auch unter normalem TOS.
Dokumentation
Obwohl die Vorversion noch ohne Handbuch und aussagekräftige Online-Hilfe ausgeliefert wurde - diese werden bei Erscheinen, vermutlich wenn Sie diese Ausgabe längst in Händen halten, nachgeliefert - skizzierte das 4seitige DIN-A5-Faltblatt die Möglichkeiten so gut, daß in Verbindung mit der sehr guten Programmoberfläche ein sofortiges Arbeiten möglich war.
Fazit
Jedem ernsthaften Pure-C- oder Pure-Pascal-Programmierer kann der Profiler nur ans Herz gelegt werden. Auch demjenigen, der ein Entwicklungssystem mit DRI-Objektcode verwendet, ist der Profiler noch eine empfehlenswerte Hilfe. Reine Assembler-Programmierer sollten sich eher nach einer Hochsprache umsehen: für einzelne Codeteile, per Pure Assembler erzeugt, eignet sich der Profiler aber durchaus. Mit seiner komfortablen Bedienung und übersichtlichen Darstellung ist er trotz einiger noch vorhandener Schwächen ein wertvolles, dennoch preiswertes Werkzeug zur Verbesserung eigener Programme.
Untersuchte Entwicklungsumgebungen
+ Pure C 1.1
+ Pure Pascal 1.1
+ GNU C 2.4.3
+ GFA-BASIC 3.6
+ TurboAss 1.71
- Lattice C 5.52
Bezugsquelle:
Application Systems Heidelberg Postfach 102646 69016 Heidelberg
Preis: 149,- DM
Pure Profiler
Positiv:
sehr gute Bedienung
alle Rechner und -Umgebungen stabil, auch unter MiNT
günstiger Preis
VDI-Font einsetzbar
Negativ:
kein hierarchisches Zeitprofil
keine Zeit pro Funktionsaufruf
nur 8*16-Systemzeichensatz
kein Betrieb unter MultiTOS
kleinere Instabilitäten
VDI-Font
Bei der Suche nach mehr Übersicht ist man nicht unbedingt auf einen größeren Monitor und Grafikkarte angewiesen. VDI-Font bietet per Software die Einrichtung eines beliebigen unproportionalen GDOS-Zeichensatzes als Systemzeichensatz, wie es ATARI für MultiTOS ebenfalls vorsieht. Fortan kümmert sich VDI-Font darum, daß für sämtliche Ausgaben der GDOS-Zeichensatz verwendet wird. Dialogboxen, Menüs und Fensterelemente werden dabei in ihrer Größe automatisch angepaßt. Das Programm selbst kommt in den AUTO-Ordner bzw. wird unter MiNT über die Konfigurationsdatei MINT.CNF gestartet. Mit einem CPX für ATARIs modulares Kontrollfeld läßt sich dann der Zeichensatz auswählen.
In der Praxis funktioniert VDI-Font nahezu problemlos, zumindest in sauber geschriebenen Programmen, die sonst keine Verwendung von GDOS-Zeichensätzen vorsehen. Insbesondere in Editoren, wie 1st Word oder Pure C, aber auch im Pure Profiler (siehe Bilder dazu), läßt sich deutlich mehr Übersicht erreichen. Einziges, prinzipielles Problem sind in Dialogen untergebrachten Icons, die ihre originale Größe behalten und nicht skaliert werden. Bei moderaten Größenänderungen im Vergleich zu den 8*16 Punkten des Originalsystemzeichensatzes stellt das jedoch kein Hindernis dar.
Man sollte seine Augen natürlich nicht durch einen zu klein gewählten Zeichensatz quälen, doch 30 statt 22 Zeilen erhöhen bereits deutlich die Übersicht. Wer mehr will, sollte sich dann wirklich zum Kauf einer Grafikkarte mit entsprechendem Monitor durchringen.
Frank Baumgart
VDI-Font von H. Sommerfeldt findet sich vorwiegend in Mailboxen und darf frei kopiert werden.
Frank Baumgart