WETTSWIL/SCHWEIZ (uk) - Bis zu 80 Prozent Performance-Verbesserungen bei LMS-PL/I-Programmen will eine Schweizer Großbank erzielt haben, seitdem sie Monitorprogramme des PL/I-Mitautors Michael R. Barnett eingesetzt hat. Der Engländer, als IBM-Angehöriger vier Jahre an der Entwicklung des PL/I-Compilers beteiligt, ist seit 1974 Mitarbeiter des Schweizer Software-Hauses HIS Consultants und beschäftigt sich primär mit Optimierungstechniken für PL/I- und IMS-Programme. Er fand als konkrete Ansatzpunkte zur Performance-Verbesserung die 11W8 Calls sowie die sogenannte "Flow Path Time" heraus und schrieb, da IBMs SMF-Daten keine programm-spezifischen Daten liefert, selbst zwei Monitorprogramme. Selbst sich "tief im System" abspielende Aktivitäten sollen mit diesen Hilfsmitteln bis aufs einzelne Programm-Statement zurückverfolgt werden können. Über die ersten Erfahrungen und Ergebnisse beim Einsatz der Meß-Tools in einer Schweitzer Bank berichtet Barnett im folgenden Beitrag.
Bei der komplexen Analyse von Software-Aktivitäten ist man gewöhnlich auf Software Monitors oder Tracing Tools angewiesen, die meist in das Betriebssystem integriert sind. Mit Hilfe der System Measurement Facilities (SMF von IBM) erhält man beispielsweise eine Menge Meßdaten über I/O-Activity, Program Loads, Supervisor Calls oder CPU-Belastung pro Region. Die Schwierigkeiten beginnen aber erst beim Versuch, diese Zeitinformationen mit spezifischen Programmen beziehungsweise Programmteilen in Beziehung zu setzen. Ein Beispiel aus unseren Performance-Untersuchungen zeigt diese Schwierigkeiten:
SMF verweist nur auf die Link Pack Area
Die genaue Überprüfung der SMF-Statistiken ergab in einem Fall eine außergewöhnlich hohe Anzahl von SPIE-SVCs im Gesamtsystem. Diese Anzahl überschritt bei weitem das in PL/I und IMS übliche. SMF konnte jedoch nur anzeigen, daß sie von der Link Pack Area (LPA) verursacht wurden. Anhand von Trace- und Dump-Informationen konnten die betreffenden Module jedoch gefunden werden. Die weitaus schwierigere Aufgabe aber war, herauszufinden, welche Programme diese Module aufgerufen hatten. Eine langwierige und aufwendige Suche durch die Source Libraries war nötig, bis es gelang, das eigentliche Problem zu isolieren: Es zeigte sich, daß die PL/I Inter Language Facilities nicht richtig angewendet worden waren.
Ansatzpunkte: IMS-Calls und "Flow Path Time"
Die Optimierung von Programmen zur Verbesserung der Performance ist ein riskantes Unternehmen mit unsicheren Erfolgsaussichten. Es ist schwierig, Aktivitäten, die sich "tief im System" abspielen, bis auf ein bestimmtes Programm oder gar ein bestimmtes Statement zurückzuverfolgen. Aus diesem Grunde entwickelten wir zwei neue Techniken zur Messung der Performance von IMS- und PL /I- Programmen:
Das erste Instrument ist ein Monitor zur Messung von IMS-Call-Statements. Es liefert eine Zeitstatistik für jedes CALL PLITDLI-Statement und über jedes Ergebnis dieses Calls, beispielsweise für "Call Function", "Status Code", "Segment Type" und "Data Base". Dabei wird zwischen interrupt-freien Messungen mit reiner CPU-Zeit und Messungen unterschieden, die durch Interrupts nur die "elapsed time" ergeben. Die Statistik vermittelt eine Vorstellung über den Anteil derjenigen Calls, die aus dem IMS Buffer Pool bedient werden konnten. Durch die Berechnung des prozentualen Anteils jedes Calls an der Gesamt-IM-Zeit im Programm erhält der Benutzer konkrete Angaben über die kritischen Stellen in seinem Programm. In vielen Fällen wurden beispielsweise redundante IMS-Calls entdeckt. Oft konnten zwei oder mehr Calls zu einem einzigen "Path Call" zusammengefaßt werden. Manchmal war es aber auch erforderlich, Änderungen im Design der Datenbanken vorzunehmen.
Ein zweites Tool basiert auf dem Konzept von "Flow Path"-Messungen. Der PL/I Optimizing Compiler enthält eine Möglichkeit, alle Verzweigungen im Programmfluß aufzuzeichnen. Eigentlich nur als Hilfsmittel zur Fehlersuche gedacht, bietet sich jedoch durch die FLOW-Option die Möglichkeit, die "execution time" zwischen zwei Verzweigungspunkten zu messen. Diese Zeit nennen wir die "Flow Path Time". Für jeden einzelnen "Flow Path" werden von dem Tool Statistiken erstellt, in denen die Programmteile mit dem größten Zeitverbrauch besonders ausgewiesen sind Genau wie bei den IMS-Call Meßtechniken werden sowohl CPU- als auch "elapsed" Zeiten aufgezeichnet. Bei der Auswertung ergaben sich verblüffende Resultate: Die Durchführungszeit eines Programmes wurde beispielsweise durch Weglassen unnötiger Referenzen auf eine große Struktur auf ein Siebentel reduziert.
90 Prozent Programm-Zeit für IMS-Calls
Mit den detaillierten Meßstatistiken der beschriebenen Tools ist es möglich, quantitativ alle Änderungen zu erfassen und die Zielsetzungen mit zunehmendem Fortschritt der Programme zu überwachen. Unsere Messungen ergaben gleich zu Beginn einen ungewöhnlich hohen Zeitanteil der untersuchten Applikationsprogramme an IMS-Routinen. Typische Programme verbrachten 70 - 90 Prozent ihrer Zeit mit dem Ausführen von IMS-Calls; der Anteil traf sowohl für Batch- als auch für Online-Programme zu. Wenn beispielsweise die gleichen Segmente täglich mehrmals gebraucht wurden, wr es effizienter, IMS-DL/I nur einmal zu benutzen, die Daten zu normalen OS-Files zu konvertieren und danach ohne IMS weiterzuarbeiten. Wir haben auf diese Art ganze IMS-Datenbanken als OS-Files gespeichert, wobei die hierarchischen Informationen durch PL/I LIST Processing gewahrt blieben. Als weitere Möglichkeit zur Reduzierung der IMS-Calls bot sich die Zusammenfassung von Daten an, die auf verschiedene Segmenttypen verteilt waren. Dies wurde auf zwei Arten realisiert: Einmal durch Zusammenfassung verschiedener Segmenttypen zu einem einzigen Segmenttyp, zum anderen durch "Blocken" von gleichen Segmenttypen (Twins) in einem Segmenttyp.
"Teures GE-Problem"
Schließlich kamen wir durch die Monitormessungen noch einem Problem auf die Spur, das wir das "teure GE-Problem" nannten. In IMS können zusätzliche Informationen in einem Segmenttyp untergebracht werden, der nur von Fall zu Fall erscheint. Wird dieser Segmenttyp unter einem physischen Parent definiert und dieser ist bereits in den Buffer eingelesen, ist es nicht allzu umständlich, anhand des Status Codes ("GE") festzustellen, ob der Segmenttyp vorhanden ist oder nicht. IMS prüft lediglich ein Pointerfeld im Parent: Eine Operation, die selbst auf den größten IBM-Rechnern einige hundert Mikrosekunden ausmacht. Muß die Existenz eines solchen Segmenttyps auf dem logischen Parent-Pfad geprüft werden, kann sich diese Zeit noch um mehr als das Hundertfache erhöhen. Hier bietet sich eine einfache technische Lösung an: Einige Bits werden irgendwo auf dem physischen Parent-Pfad als Indikator für das Vorhandensein eines abhängigen Segmenttyps eingesetzt. Dies ist zwar eine "Data Management in der Applikation"- Lösung; die aber durch 20 - 30 Prozent Performance-Verbesserung gerechtfertigt sein dürfte.
Achtung bei der Feld-Aufteilung!
Es muß sorgfältig unterschieden werden zwischen Verbesserung von Algorithmen und von PL/I-Code. Auch ein noch so gutes Tunen des Codes kann den Schaden durch schlechte Algorithmen nicht kompensieren: Ein Punkt, der von vielen Programmierern übersehen wird. Wenn beispielsweise einfache Statements, wie das Initialisieren großer Strukturen mit einem NULL String auch nur einige Male vorkommen, können sie einen Großteil der Programmlaufdauer ausmachen. Hier findet man oft bessere Initialisierungsmethoden oder verzichtet auf die Initialisierung einiger Felder. Auch das "BY NAME"-Zuordnungs-Statement hat sich als großer Zeitverschwender herausgestellt. Mehr Sorgfalt bei der Aufteilung von Feldern sowie dem Gebrauch von sich überlagernden Character Strings und größere Aufmerksamkeit bei der Standardisierung von Data Attributes sind erforderlich auf dem Weg zu effizienteren Programmen.
Fehlerquelle "File-Handling"
Soweit individuelle PL/I-Statements davon betroffen sind, haben sich zwei weitere Bereiche dieser Sprache als beständige Fehlerquelle erwiesen. So wäre beim File Handling eine große Verbesserung des Optimizer Codes mit der TOTAL-Option möglich. Bei Indexed Files zeigte der Einsatz unseres Monitors einen weiteren Fehler: den Gebrauch von Queued Access Methods, obwohl die Basic Methods ausreichend wären.
Eine weitere, wichtige PL/-Lektion, die wir lernen mußten, war die richtige Anwendung von Bit- und Character- Konstanten anstelle von Variablen. Es ist zwar das Gütezeichen eines erfahrenen Programmierers, symbolische Namen statt Konstante zu verwenden. Leider ist es aber auch das Gütezeichen eines guten Compilers, besseren Code aus Konstanten als von Variablen zu generieren.
Michael R. Barnett studierte von 1957 bis 1960 in Manchester/England Physik und war danach acht Jahre Mitarbeiter der IBM Laboratories in Hursley. In dieser Zeit war er zunächst an der Entwicklung des PL/I-Compilers beteiligt und gab sein Wissen anschließend als Instruktur für PL/I-Informationssysteme und Betriebssysteme an der IBM-Universität in Genf weiter.