DE10039538A1 - Vorrichtung und Methode zum Analysieren der Leistung eines Computerprogramms - Google Patents
Vorrichtung und Methode zum Analysieren der Leistung eines ComputerprogrammsInfo
- Publication number
- DE10039538A1 DE10039538A1 DE10039538A DE10039538A DE10039538A1 DE 10039538 A1 DE10039538 A1 DE 10039538A1 DE 10039538 A DE10039538 A DE 10039538A DE 10039538 A DE10039538 A DE 10039538A DE 10039538 A1 DE10039538 A1 DE 10039538A1
- Authority
- DE
- Germany
- Prior art keywords
- computer program
- performance data
- program
- query
- code segment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/323—Visualisation of programs or trace data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3476—Data logging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/815—Virtual
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Data Mining & Analysis (AREA)
- Debugging And Monitoring (AREA)
Abstract
Eine Vorrichtung und eine Methode, die das Analysieren der Leistung eines Computerprogramms ermöglichen. Das Computerprogramm wird zunächst entsprechend einem vordefinierten Satz von Programmausführungsbedingungen ausgeführt. Während das Computerprogramm abläuft, werden Informationen über jedes Codesegment protokolliert. Anhand der protokollierten Leistungsdaten wird eine graphische Darstellung des ausgeführten Computerprogramms aufgebaut. Ein Benutzer kann dann ad-hoc-Abfragen formulieren, um jeden gewünschten Leistungsparameter für das Computerprogramm zu analysieren, indem wiederholt wird, wie das Computerprogramm ablief, und zwar unter Anwendung einer graphischen Darstellung des ausgeführten Computerprogramms. Die vorliegende Erfindung ermöglicht es somit einem Benutzer, mit Hilfe von Abfragen komplexe Leistungsengpässe zu erkennen, die durch Wechselwirkungen zwischen mehreren Codesegmenten verursacht werden.
Description
Diese Erfindung betrifft allgemein die Computerprogrammierung
und im einzelnen eine Vorrichtung und Methoden zum Messen und
Analysieren der Leistung eines Computerprogramms.
Seit Beginn des Computerzeitalters haben sich die
Computersysteme zu äußerst hochentwickelten Einrichtungen
entwickelt, die in vielen verschiedenen Ausführungen zu finden
sind. Computersysteme umfassen typischerweise eine Kombination
verschiedener Hardwarekomponenten, beispielsweise Halbleiter
und Leiterplatten, und Softwarekomponenten, die
Computerprogramme. Da durch die Fortschritte in der
Halbleiterverarbeitung und der Computerarchitektur die
Leistung der Computerhardware immer besser wurde, entstand
auch eine höherentwickelte Computersoftware, mit der die
höhere Leistung der Hardware genutzt werden konnte. Die
heutigen Computersysteme sind daher wesentlich
leistungsfähiger als noch vor wenigen Jahren.
Je höher entwickelt und komplizierter eine Computersoftware
ist, desto schwieriger ist die Prüfung ihrer Leistung.
Softwareanwendungen bestehen typischerweise aus einer Reihe
von benannten Codesegmenten, die je nach Art der verwendeten
Programmiersprache als Prozeduren, Funktionen, Module, Objekte
etc. bekannt sind. Objektorientierte Anwendungen sind
gekennzeichnet durch viele kleine Codesegmente, Methoden
genannt, die mit anderen Methoden auf komplexe Weise
zusammenwirken. Mit zunehmender Größe einer Softwareanwendung
wird es daher immer schwieriger, die Ursache von
Leistungsengpässen einer Anwendung festzustellen. Bekannte
Tools zur Leistungsanalyse erkennen Leistungsengpässe in einem
bestimmten Codesegment. In einer komplexen Softwareanwendung
entstehen Leistungsengpässe oft aber nicht durch ein
bestimmtes Codesegment, sondern aus der Art und Weise, wie
viele dieser Codesegmente miteinander agieren. Aus diesem
Grund können mit den bekannten Leistungsanalysetools
Leistungsengpässe, die durch Interaktionen zwischen mehreren
Codesegmenten entstehen, nicht erkannt werden. Ohne einen
Mechanismus und eine Methode zur Erkennung dieser schwer
erfaßbaren Leistungsengpässe wird die Computerindustrie auch
weiterhin an den ineffizienten Methoden und Tools zur
Leistungsanalyse eines Computerprogramms kranken.
Gemäß der vorliegenden Erfindung kann mit einer Vorrichtung
und einer Methode die Leistung eines Computerprogramms
analysiert werden. Das Computerprogramm läuft zunächst nach
einem vordefinierten Satz von Programmausführungsbedingungen
ab. Während das Computerprogramm abläuft, werden Informationen
für jedes Codesegment protokolliert. Mit Hilfe der
protokollierten Leistungsdaten wird eine graphische
Darstellung des ausgeführten Computerprogramms erstellt. Ein
Benutzer kann dann ad-hoc-Abfragen formulieren, um jeden
gewünschten Leistungsparameter für das Computerprogramm zu
analysieren, indem er durch Anwendung der graphischen
Darstellung des ausgeführten Computerprogramms den Ablauf des
Computerprogramms wiederholt. Mit der vorliegenden Erfindung
kann ein Benutzer also mit Hilfe von Abfragen komplizierte
Leistungsengpässe erkennen, die durch Interaktionen zwischen
mehreren Codesegmenten verursacht werden.
Die oben genannten sowie andere Merkmale und Vorteile der
Erfindung werden anhand der folgenden ausführlicheren
Beschreibung der bevorzugten Ausführungsbeispiele der
Erfindung deutlich, die in den beiliegenden Zeichnungen
dargestellt sind.
Die bevorzugten Ausführungsbeispiele der vorliegenden
Erfindung sollen im folgenden in Verbindung mit den
Zeichnungen im Anhang beschrieben werden, wobei gleiche
Benennungen gleiche Elemente bezeichnen. Es zeigt:
Fig. 1 ein Blockdiagramm einer Vorrichtung entsprechend den
bevorzugten Ausführungsbeispielen der vorliegenden Erfindung;
Fig. 2 ein Flußschema einer Methode zum Messen und Analysieren
der Leistung eines Computerprogramms entsprechend den
vorliegenden Ausführungsbeispielen;
Fig. 3 ein Flußschema einer Methode zum Protokollieren von
Informationen für ein benanntes Codesegment, während das
Codesegment entsprechend den bevorzugten Ausführungsbeispielen
abläuft;
FIGS. 4-9 Pseudocode-Darstellungen verschiedener Codesegmente,
die ein Muster-Computerprogramm zur Darstellung der Grundlagen
der bevorzugten Ausführungsbeispiele bilden;
Fig. 10 eine graphische Darstellung des
Computerprogrammablaufs mit den Codesegmenten der FIGS. 4-9;
und
Fig. 11 eine Abfragetabelle mit den Ergebnissen verschiedener
Abfragen, die durch Wiederholen des Computerprogramms unter
Anwendung der graphischen Darstellung der Fig. 10 durchgeführt
werden.
Gemäß den bevorzugten Ausführungsbeispielen der vorliegenden
Erfindung kann ein Benutzer mit Hilfe einer Vorrichtung und
einer Methode Leistungsdaten sammeln, indem er ein
Computerprogramm ablaufen läßt, und ad-hoc-Abfragen
durchführen, um relevante Leistungsparameter aus den
gesammelten Leistungsdaten zu ermitteln. Die Vorrichtung und
die Methode der bevorzugten Ausführungsbeispiele sind flexible
und leistungsfähige Tools zur Analyse der Leistung eines
Rechnerprogramms.
Bezugnehmend auf Fig. 1; ein Computersystem 100 gemäß dem
bevorzugten Ausführungsbeispiel ist ein verbessertes IBM
AS/400 Computersystem. Ein Fachmann wird jedoch erkennen, dass
die Mechanismen und die Vorrichtung der vorliegenden Erfindung
auch auf jedes andere Computersystem anwendbar sind,
unabhängig davon, ob das Computersystem ein kompliziertes
Rechnersystem für mehrere Benutzer oder eine Workstation für
nur einen Benutzer ist. Wie in Fig. 1 gezeigt wird, umfasst
das Computersystem 100 einen Prozessor 110, der mit einem
Hauptspeicher 120, einer Massenspeicherschnittstelle 130,
einer Terminalschnittstelle 140 und einer Netzschnittstelle
150 verbunden ist. Diese Systemkomponenten sind über einen
Systembus 160 miteinander verbunden. Die
Massenspeicherschnittstelle 130 dient zum Anschluß der
Massenspeichervorrichtungen (beispielsweise ein
Direktzugriffsspeicher 155) an das Computersystem 100. Ein
spezieller Direktzugriffsspeicher ist ein Diskettenlaufwerk,
mit dem Daten auf eine Diskette 195 gespeichert bzw. von
dieser gelesen werden können.
Der Hauptspeicher 120 enthält die Daten 122, ein
Betriebssystem 124, ein Computerprogramm 125 und einen
Computerprogramm-Leistungsanalysator 131. Das Computerprogramm
umfasst mehrere Codesegmente 126, die jeweils vorzugsweise
einen eindeutigen Namen haben. Der Computerprogramm-
Leistungsanalysator 131 umfasst einen Satz von
Programmausführungsbedingungen 132, einen Codesegment-Logger
133, einen Graphikprogrammgenerator 134, ein Abfrage-Tool 135
und einen Programmwiederholungsmechanismus 136. Jedes dieser
Elemente wird im folgenden ausführlich erörtert. Das
Computersystem 100 nutzt die bekannten virtuellen
Adressierungsmechanismen, die es den Programmen des
Computersystems 100 ermöglichen, sich so zu verhalten, als ob
sie nicht auf viele kleinere Speichereinheiten, wie
beispielsweise den Hauptspeicher 120 und die DASD-Einrichtung
155, zugreifen müßten, sondern nur auf eine einzige große
Speichereinheit. Die Daten 122, das Betriebssystem 124, das
Computerprogramm 125 und der Computerprogramm-
Leistungsanalysator 131 befinden sich deswegen auf der
Abbildung im Hauptspeicher 120. Der Fachmann wird jedoch
erkennen, dass diese Einrichtungen nicht notwendigerweise alle
gleichzeitig komplett im Hauptspeicher 120 enthalten sind.
Außerdem ist zu beachten, dass mit dem Begriff "Speicher" hier
generisch auf den gesamten virtuellen Speicher des
Computersystems 100 hingewiesen wird.
Die Daten 122 sind Daten, die als Eingang in oder Ausgang aus
einem Programm des Computersystems 100 dienen. Das
Betriebssystem 124 ist ein Multitasking-Betriebssystem, das in
der Branche unter dem Namen OS/400 bekannt ist; der Fachmann
wird jedoch erkennen, dass Prinzip und Umfang der vorliegenden
Erfindung nicht auf ein bestimmtes Betriebssystem begrenzt
sind. Das Computerprogramm 125 stellt ein Computerprogramm
jeder beliebigen Form dar, entweder mit Quellcode, in Form
einer Zwischensprache, als Maschinencode oder eine andere
Form. Das Computerprogramm 125 kann Systemprogramme (z. B. ein
Betriebssystem), Anwendungsprogramme oder alle anderen Arten
und Formen von Computerprogrammen umfassen. Das
Computerprogramm 125 besteht aus mehreren Codesegmenten 126.
Die Codesegmente 126 können Prozeduren, Funktionen, Routinen,
Subroutinen, Objektmethoden und jeden anderen Teil eines
ausführbaren Codes in einem Computerprogramm umfassen, der
durch einen eindeutigen Namen gekennzeichnet werden kann. Die
Art der Codesegmente 126 in einem Computerprogramm 125 hängt
zum großen Teil von der Programmiersprache ab, die zur
Definition des Computerprogramms 125 eingesetzt wird.
Der Computerprogramm-Leistungsanalysator 131 ist ein Werkzeug,
mit dem Leistungsdaten für das Computerprogramm 125 gesammelt
werden. Anhand dieser Leistungsdaten kann ein Benutzer
Leistungsengpässe und andere, damit zusammenhängende
Eigenschaften des Computerprogramms 125 identifizieren. Um
Leistungsdaten für das Computerprogramm 125 zu sammeln, werden
die Programmausführungsbedingungen 132 festgelegt. Das
Computerprogramm 125 läßt man dann unter diesen festgelegten
Bedingungen 132 ablaufen. Der Begriff
"Programmausführungsbedingungen" ist ein sehr weit gefaßter
Begriff, der sämtliche Definitionen und Bedingungen enthält,
die für den Ablauf des Computerprogramms festgelegt werden
müssen. Wenn beispielsweise das Computerprogramm an einem
bestimmten Punkt auf eine Eingabe des Benutzers warten soll,
könnten die Programmausführungsbedingungen 125 eine bestimmte
Benutzereingabe enthalten, die bewirkt, dass das
Computerprogramm die gewünschten Funktionen ausführt. Wenn das
Computerprogramm bedingte Verzweigungen hat, könnten die
Programmausführungsbedingungen 125 eine Spezifikation der
Bedingung enthalten, um sicherzustellen, dass ein bestimmter
Abzweig genommen wird. Bei einem komplexen Programm sind daher
Anzahl und Art der Programmausführungsbedingungen 132 ziemlich
umfangreich.
Wenn die Programmausführungsbedingungen 132 definiert sind,
wird das Computerprogramm 125 unter diesen Bedingungen
ausgeführt. Ein Codesegment-Logger 133 protokolliert Daten für
jedes Codesegment, während dieses abläuft. In den bevorzugten
Ausführungsbeispielen protokolliert der Codesegment-Logger 133
die Zeit, die er für die Ausführung des aktuellen Codesegments
und für die anderen Codesegmente benötigt hat, die aufgerufen
wurden, während das aktuelle Codesegment ablief. Nachdem der
Codesegment-Logger 133 Leistungsdaten für alle Codesegmente
126 in dem Computerprogramm 125 protokolliert hat, werden
diese protokollierten Leistungsdaten von einem
Graphikprogrammgenerator 134 verwendet, um eine graphische
Darstellung des Computerprogramms 125 zu erzeugen, welche die
Leistungsdaten enthält. Nachdem die graphische Darstellung der
Leistungsdaten von dem Graphikprogrammgenerator 134 erzeugt
wurde, kann ein Benutzer mit Hilfe des Abfrage-Tools 135
benutzerdefinierte ad-hoc-Abfragen über die Leistungsdaten in
der graphischen Darstellung durchführen. Wenn der Benutzer
eine Abfrage macht, wird das Computerprogramm von einem
Programmwiederholungsmechanismus 136 anhand der graphischen
Darstellung der Leistungsdaten "wiederholt". Das
Computerprogramm wird "wiederholt", indem die graphische
Darstellung schrittweise durchlaufen wird und bei jedem
Schritt Informationen (Abfragedaten) gesammelt werden, die
sich auf die Abfrage beziehen.
Der Prozessor 110 kann aus einem oder mehreren
Mikroprozessoren und/oder integrierten Schaltungen aufgebaut
werden. Der Prozessor 110 führt Programmbefehle aus, die im
Hauptspeicher 120 gespeichert sind. In der vorliegenden
Beschreibung bedeutet der Begriff "CPU-Zyklen" die Anzahl der
Zyklen für den Prozessor 110. Der Hauptspeicher 120 speichert
Programme und Daten, auf die der Prozessor 110 zugreifen kann.
Wenn das Computersystem 100 gestartet wird, führt der
Prozessor 110 zunächst die Programmbefehle aus, aus denen das
Betriebssystem 124 besteht. Das Betriebssystem 124 ist ein
hochentwickeltes Programm, mit dem die Ressourcen des
Computersystems 100 verwaltet werden. Einige dieser Ressourcen
sind der Prozessor 110, der Hauptspeicher 120, die
Massenspeicherschnittstelle 130, die Terminalschnittstelle
140, die Netzschnittstelle 150 und der Systembus 160.
Obwohl das Computersystem 100 in der Abbildung nur einen
einzigen Prozessor und einen einzigen Systembus enthält, wird
ein Fachmann erkennen, dass die vorliegende Erfindung mit
einem Computersystem realisiert werden kann, das über mehrere
Prozessoren und/oder mehrere Busse verfügt. Außerdem umfassen
die in dem bevorzugten Ausführungsbeispiel verwendeten
Schnittstellen voll programmierte Mikroprozessoren, die den
Prozessor 110 bei rechenintensiven Vorgängen entlasten. Ein
Fachmann wird jedoch erkennen, dass die vorliegende Erfindung
gleichermaßen für Computersysteme gilt, die zur Ausführung
ähnlicher Funktionen einfach E/A-Adapter verwenden.
Die Terminalschnittstelle 140 dient zum direkten Anschluß
eines oder mehrerer Terminals 165 an das Computersystem 100.
Diese Terminals 165, die keine intelligenten Terminals oder
voll programmierbare Workstations sein müssen, dienen
Systemverwaltern und Benutzern zur Kommunikation mit dem
Computersystem 100. Man beachte jedoch, dass die
Terminalschnittstelle 140 zwar die Kommunikation mit einem
oder mehreren Terminals 165 unterstützen soll, dass aber das
Computersystem 100 nicht notwendigerweise ein Terminal 165
benötigt, da sämtliche Interaktionen mit Benutzern und anderen
Prozessen über die Netzschnittstelle 150 stattfinden können.
Die Netzschnittstelle 150 dient zum Anschluß anderer
Computersysteme und/oder Workstations (z. B. 175 in Fig. 1) an
das Computersystem 100 über das Netzwerk 170. Die vorliegende
Erfindung ist unabhängig davon anwendbar, wie das
Computersystem 100 an andere Computersysteme und/oder
Workstations angeschlossen ist und unabhängig davon, ob der
Netzwerkanschluß 170 mit den heutigen analogen und/oder
digitalen Techniken oder mit einem Vernetzungsmechanismus der
Zukunft durchgeführt wird. Außerdem können viele verschiedene
Netzwerkprotokolle zur Implementierung eines Netzwerks
verwendet werden. Diese Protokolle sind spezialisierte
Computerprogramme, mit denen Computer in einem Netzwerk 170
miteinander kommunizieren können. TCP/IP (Transmission Control
Protocol/Internet Protocol) ist ein Beispiel für ein
geeignetes Netzwerkprotokoll.
An dieser Stelle muß darauf hingewiesen werden, dass die
vorliegende Erfindung bisher und auch im folgenden in
Zusammenhang mit einem voll funktionsfähigen Computersystem
beschrieben wurde, dass jedoch der Fachmann erkennen wird,
dass die vorliegende Erfindung als Programmprodukt in
unterschiedlicher Form in den Handel gebracht werden kann und
dass die vorliegende Erfindung unabhängig vom jeweiligen
signaltragenden Medium gilt, das tatsächlich für den Vertrieb
eingesetzt wird. Beschreibbare Medien, z. B. Disketten (z. B.
195 in Fig. 1) und CD ROM, sowie Übertragungsmedien, z. B.
digitale und analoge Datenübertragungsabschnitte, sind
Beispiele für geeignete signaltragende Medien.
Der restliche Teil dieser Beschreibung informiert darüber, wie
der Computerprogramm-Leistungsanalysator 131 Leistungsdaten
sammelt und es dem Benutzer ermöglicht, ad-hoc-Abfragen zu
spezifizieren, die dabei helfen, die zugehörigen Aspekte des
Computerprogramms, beispielsweise Leistungsengpässe, ausfindig
zu machen. Bezugnehmend auf Fig. 2; eine Methode 200 zum
Sammeln und Analysieren von Leistungsdaten beginnt mit der
Protokollierung von Daten für jedes Codesegment des
Computerprogramms (Schritt 210). In den bevorzugten
Ausführungsbeispielen erfolgt die Protokollierung der Daten
für jedes Codesegment in Schritt 210, während das
Computerprogramm mit den vordefinierten
Programmausführungsbedingungen 132 ausgeführt wird. Die
Ausführungszeit eines Codesegments kann mit bekannten
Mechanismen gemessen werden. Beispielsweise könnten
Softwaremechanismen eingesetzt werden, welche die Zeit oder
die Anzahl der für die Ausführung eines Codesegments
erforderlichen CPU-Zyklen messen oder schätzen. Alternativ
kann ein Hardware-Timer verwendet werden, um die
Ausführungszeit oder die Anzahl von CPU-Zyklen für das
Codesegment direkt zu messen. Ein solcher Hardware-Timer
könnte beispielsweise verwendet werden, wenn ein logischer
Analysator zur Erzeugung einer Programm-Verfolgungsspur über
die Ausführung des Computerprogramms eingesetzt wird. Diese
Programm-Verfolgungsspur kann später analysiert werden, um die
Ausführungszeit für jedes Codesegment und die (gegebenenfalls)
von jedem Codesegment aufgerufenen Codesegmente zu bestimmen.
Neben der Protokollierung von Daten in einer Programm-
Verfolgungsspur des Computerprogramms schließt der Umfang der
bevorzugten Ausführungsbeispiele auch die Bereitstellung von
Protokolldaten ein, die durch eine statistische Analyse des
Codes und eine Bestimmung der Ausführungszeit für ein
Codesegment, basierend auf einer vorgegebenen Prozessorzeit
zur Ausführung eines Befehls und basierend auf festgestellten
Annahmen bezüglich der Cache-Trefferrate, der
Speichergeschwindigkeit etc., abgeleitet werden. Schritt 210
enthält speziell alle Mechanismen und Methoden zur
Protokollierung von Leistungsdaten für ein Codesegment 126 in
einem Computerprogramm 125.
Nachdem die Protokollierung der Daten in Schritt 210
abgeschlossen ist, wird eine graphische Darstellung des
Computerprogramms aufgebaut (Schritt 220). Diese enthält die
in Schritt 210 protokollierten Leistungsdaten. In dem
bevorzugten Ausführungsbeispiel erzeugt Schritt 220 einen
Datenstrukturbaum (wie er beispielsweise in Fig. 10
dargestellt ist), wobei jede Datenstruktur ein ausgewähltes
Codesegment darstellt und Daten enthält, die sich auf die
Ausführungszeit des ausgewählten Codesegments beziehen und
wobei durch den Aufbau des Baumes festgelegt wird, welche
Codesegmente von anderen Codesegmenten aufgerufen werden.
Nachdem die graphische Darstellung des Computerprogramms in
Schritt 220 aufgebaut wurde, kann ein Benutzer eine oder
mehrere Abfragen (Schritt 230) formulieren, um die Leistung
des Computerprogramms zu ermitteln.
Nachdem in Schritt 230 eine Abfrage definiert wurde, läßt man
das Programm erneut ablaufen, indem die Datenstrukturen in der
graphischen Darstellung des Computerprogramms durchgearbeitet
werden, um die Abfragedaten zu sammeln (Schritt 240). Die
Abfragedaten werden dann an den Benutzer ausgegeben (Schritt
250). Wenn mehr Abfragen benötigt werden (Schritt 260 = JA),
schleift die Methode 200 zurück und wird bei Schritt 230
fortgesetzt. Wenn keine weiteren Abfragen benötigt werden
(Schritt 260 = NEIN), ist die Methode 200 beendet.
Die Methode 200 bietet im Vergleich zu den bisherigen
Leistungsanalysetechniken wesentlich mehr Flexibilität bei der
Analyse der Leistung eines Computerprogramms. Mit dem
bisherigen Stand der Technik können nur Leistungsengpässe in
einem einzelnen Codesegment festgestellt werden. Mit der
Methode 200 hat der Benutzer die Möglichkeit, ad-hoc-Abfragen
zu spezifizieren (Schritt 230), mit denen aufgedeckt werden
kann, dass eine Gruppe von Codesegmenten oder Interaktionen
zwischen Codesegmenten einen oder mehrere Leistungsengpässe
verursachen, obwohl kein einzelnes Codesegment für sich einen
Leistungsengpaß darstellt.
Bei einer geeigneten Möglichkeit zur Protokollierung von
Leistungsdaten gemäß den bevorzugten Ausführungsbeispielen in
Schritt 210 der Fig. 2 wird die in Fig. 3 gezeigte Methode 300
eingesetzt. Methode 300 wird aufgerufen, wenn ein benanntes
Codesegment aufgerufen wird (Schritt 310). Während das
Codesegment ausgeführt wird, verfolgt der Logger die
Ausführungszeit für das Codesegment (Schritt 320) sowie für
andere aufgerufene Codesegmente (Schritt 330). Nachdem diese
Information protokolliert ist, ist Methode 300 beendet.
Ein spezifisches Beispiel eines Computerprogramms und dafür,
wie die bevorzugten Ausführungsbeispiele die Leistungsdaten
sammeln und eine Analyse dieser Daten ermöglichen, ist in den
FIGS. 4-11 dargestellt. Ein Muster eines Pseudocode-Programms
besteht aus den verschiedenen Funktionen der FIGS. 4-9,
nämlich den Funktionen A, B, C1, C2, D und E. Wie auf der
Zeichnung mit den FIGS. 4-9 zu erkennen ist, dienen die drei
vertikalen Punkte der Darstellung eines jeden Codes innerhalb
der Funktion (d. h., des linearen Codes), der keine andere
Funktion aufruft. Wie in Fig. 4 gezeigt wird, enthält Funktion
A einen Aufruf für Funktion C1 und einen Aufruf für Funktion
C2. Bezugnehmend auf Fig. 5; Funktion B enthält einen Aufruf
für Funktion E. Bezugnehmend auf Fig. 6; Funktion C1 enthält
einen Aufruf für Funktion D und einen Aufruf für Funktion E.
Wie in Fig. 7 gezeigt wird, enthält Funktion C2 einen Aufruf
für Funktion B und zwei Aufrufe für Funktion E. Die FIGS. 8
und 9 zeigen, dass weder Funktion D noch Funktion E eine der
anderen Funktionen in dem Computerprogramm aufrufen. Es ist zu
beachten, dass die spezifischen Aufrufe in den FIGS. 4-9
beliebig gewählt wurden, um die Grundprinzipien der
bevorzugten Ausführungsbeispiele darzustellen.
Nachdem das Computerprogramm durch die Funktionen in FIGS.
4-9 definiert ist, können wir uns nun Schritt für Schritt
durch die Methode 200 der Fig. 2 bewegen, um die bevorzugten
Ausführungsbeispiele unter Anwendung dieses spezifischen
Beispiels darzustellen. Zunächst wird das Computerprogramm
ausgeführt und die Methode 200 protokolliert Daten für jedes
Codesegment in dem Computerprogramm. Für das Beispiel in FIGS.
4-9 bedeutet dies, dass die Methode 200 die Leistungsdaten für
jede der Funktionen A, B, C1, C2, D und E protokolliert. Die
Leistungsdaten enthalten die Ausführungszeit für jede Funktion
(für dieses Beispiel in CPU-Zyklen ausgedrückt) und eine Liste
von Funktionen, die von den einzelnen Funktionen aufgerufen
werden. Aus diesen protokollierten Leistungsdaten erstellt
dann die Methode 200 eine graphische Darstellung des
ausgeführten Programms, das die protokollierten Daten enthält.
Ein Beispiel für eine geeignete graphische Darstellung 1000
ist in Fig. 10 dargestellt. Hier wurden die protokollierten
Ausführungszeiten für jede Funktion in CPU-Zyklen ausgedrückt
und die protokollierten Funktionsaufrufe wurden durch die
Baumkonfiguration in Fig. 10 ausgedrückt, die anzeigt, welche
Funktionen durch andere Funktionen aufgerufen wurden. Die
graphische Darstellung 1000 umfasst eine Datenstruktur für
jede Funktion, welche die Ausführungszeit für diese Funktion
in CPU-Zyklen enthält. Funktion A hat eine entsprechende
Datenstruktur 1005, die zeigt, dass für die Ausführung der
Funktion A 16 CPU-Zyklen benötigt wurden. Funktion C1 hat eine
entsprechende Datenstruktur 1010, die zeigt, dass für die
Ausführung der Funktion C1 26 CPU-Zyklen benötigt wurden.
Funktion C2 entspricht die Datenstruktur 1050, die zeigt, dass
für die Ausführung der Funktion C2 36 CPU-Zyklen nötig waren.
Funktion B entspricht die Datenstruktur 1060, die zeigt, dass
für die Ausführung der Funktion B 46 CPU-Zyklen benötigt
wurden. Funktion D entspricht die Datenstruktur 1030, die
zeigt, dass für die Ausführung der Funktion D 6 CPU-Zyklen
benötigt wurden. Funktion E entsprechen mehrere
Datenstrukturen, 1020, 1040, 1070, 1080 und 1090; jede dieser
Datenstrukturen zeigt, dass für jeden Pfad, mit dem die
Funktion E erreicht wurde, zum Ausführen der Funktion E 10
CPU-Zyklen nötig waren. Die graphische Darstellung 1000
umfasst außerdem die numerierten Pfade 1-9, um die
nachstehende Beschreibung der Abfragen in Fig. 11 zu
vereinfachen.
Man beachte, dass das bevorzugte Ausführungsbeispiel, wie es
in Fig. 1 gezeigt wird, einen Codesegment-Logger 133 und einen
Graphikprogrammgenerator 134 enthält. Das bedeutet, dass die
Leistungsdaten zunächst von dem Codesegment-Logger 133
protokolliert und die protokollierten Leistungsdaten dann mit
Hilfe des Graphikprogrammgenerators 133 in eine graphische
Darstellung des Programms konvertiert werden. Es gehört jedoch
auch zum Umfang der bevorzugten Ausführungsbeispiele, dass der
Codesegment-Logger 133 sowohl die Leistungsdaten protokolliert
als auch dynamisch eine graphische Darstellung des
Computerprogramms aufbaut, während dieses abläuft. Die
Funktionen des Graphikprogrammgenerators 134 könnten also im
Rahmen der bevorzugten Ausführungsbeispiele auch in den
Codesegment-Logger 133 eingebaut werden.
Nachdem die graphische Darstellung des Programms erstellt ist,
wie in Fig. 10 dargestellt, kann der Benutzer das Abfrage-Tool
135 (Fig. 1) einsetzen, um ad-hoc-Abfragen über die
Leistungsdaten zu erzeugen, und so verschiedene
Leistungsattribute, beispielsweise Leistungsengpässe, zu
ermitteln. Bezugnehmend auf Fig. 11; eine Abfragetabelle 1100
zeigt sechs spezifische Abfragen 1110-1160, anhand derer
dargestellt werden soll, wie die graphische Darstellung in
Fig. 10 eingesetzt wird, um Informationen (die in diesem
Zusammenhang Abfragedaten genannt werden) für die einzelnen
Abfragen zu generieren. Aus der Legende in Fig. 11 kann man
erkennen, dass das Abfrage-Tool 135 einen Platzhalter
festlegt. Dies bedeutet, dass alle 0 bis N Funktionsaufrufe,
welche den Platzhalter ersetzen, die Abfrage betreffen. Mit
der Bezeichnung "→" wird angezeigt, dass eine Funktion eine
andere Funktion aufruft. Das Beispiel A → B → C → D paßt zu
Abfrage A → Platzhalter → D. "*" ist ein Operator, der jedes
Suffix für die Zeichen vor "*" enthält. Beispiel: C* bedeutet
jede Funktion, die mit dem Großbuchstaben C beginnt, was in
unserem Beispiel sowohl C1 als auch C2 beinhaltet.
In Abfrage 1110 werden alle CPU-Zyklen für Funktion E
abgefragt. Als Antwort wird die gesamte Anzahl von CPU-Zyklen
für jedes Vorkommen der Funktion E addiert. In der graphischen
Darstellung 1000 der Fig. 10 kommt Funktion E fünfmal vor, und
zwar 1020, 1040, 1070, 1080 und 1090. Das Programm wird
wiederholt, indem schrittweise die graphische Darstellung 1000
durchlaufen wird, um jedes Vorkommen der Funktion E zu finden.
Jedes Vorkommen nimmt 10 CPU-Zyklen in Anspruch, insgesamt 50
CPU-Zyklen für die Funktion E, wie die Ergebnisspalte der
Abfragetabelle 1100 der Fig. 11 für die Abfrage 1110 zeigt.
Abfrage 1120 fragt die CPU-Zyklen für
C2 → Platzhalter → E ab. Das bedeutet, dass die CPU-Zyklen für
jede Funktion E, die von der Funktion C2 erreicht wird, in dem
Ergebnis enthalten sind. Der "Platzhalter"-Operator umfasst
die Pfade 6-9, 7 und 8, um eine Funktion E zu erreichen, und
das Ergebnis wird erreicht, indem man mit Funktion C2 1050
beginnt und die Ausführung des Computerprogramms durch
Zurückverfolgen der möglichen Ausführungspfade (die
Ausführungssequenzen von Codesegmenten festlegen) und
Berechnen aller CPU-Zyklen, die die Kriterien erfüllen,
wiederholt. Für Abfrage 1120 enthalten alle CPU-Zyklen für
Funktion E, welche die Abfrage erfüllen, die CPU-Zyklen für
Funktion E in 1070, 1080 und 1090, insgesamt 30.
In der nächsten Abfrage 1130 wird gefordert, dass die CPU für
C* → den Zyklus durchläuft. Weil der *-Operator alle Suffixe
für den Buchstaben C umfasst, erfüllen beide Funktionen, C1
und C2 den C*-Teil für diese Abfrage. Das Vorkommen der
Funktion E, welches diese Abfrage erfüllt, ist 1020 und 1040
(bis C1) und 1070 bis 1080 (bis C2). Wenn das Computerprogramm
wiederholt wird, indem schrittweise die graphische Darstellung
1000 abgearbeitet wird, werden die CPU-Zyklen für jedes dieser
vier Vorkommen addiert, so dass sich für diese Abfrage 1130
ein Ergebnis von 40 ergibt, wie in der Abfragetabelle 1100
dargestellt ist.
Mit Abfrage 1140 werden die CPU-Zyklen für C2 → E abgefragt.
Die Pfade, die diese Abfrage beantworten, sind Pfad 7 bis 1070
und Pfad 8 bis 1080. Wenn das Programm wiederholt wird, indem
diese graphische Darstellung 1000 schrittweise abgearbeitet
wird, werden die CPU-Zyklen in 1070 und 1080 addiert und man
erhält für diese Abfrage 1140 ein Ergebnis von 20, wie in
Abfragetabelle 1100 zu sehen ist. Man beachte, dass Funktion E
bei 1090 auch berücksichtigt wird, obwohl sie von Funktion C2
bis Funktion B fließt, weil die Abfrage C2 → E verlangt, dass
C2 E direkt aufruft.
Abfrage 1150 fragt die CPU-Zyklen für C2 → B → ab. Es gibt nur
einen Pfad, der diese Abfrage betrifft, und zwar Pfad 6-9 zu
1090. Wenn das Programm durch schrittweises Durchlaufen der
graphischen Darstellung 1000 wiederholt wird, werden die CPU-
Zyklen in 1090 gesammelt, so dass sich als Ergebnis für diese
Abfrage 1150 eine 10 ergibt, wie in Abfragetabelle 1100 zu
sehen ist.
Abfrage 1160 fragt die CPU-Zyklen für D → E → ab. Funktion E
wird von Funktion D nie aufgerufen. Das Ergebnis dieser
Abfrage ist also Null. Wenn das Programm durch schrittweises
Durchlaufen der graphischen Darstellung 1000 wiederholt wird,
wird das Abfrage-Tool 135 feststellen, dass keine der
Funktionen diese Kriterien erfüllt. Das Ergebnis für diese
Abfrage 1160 ist also Null, wie in der Abfragetabelle 1100 zu
sehen ist.
Die Ergebnisse der Abfragen in Fig. 11 setzen voraus, dass der
Benutzer nur an den CPU-Zyklen der letzten Funktion in der
Abfrage interessiert ist. In Abfrage 1120 werden also nur
diejenigen Zyklen für Funktion E in das Ergebnis einbezogen,
welche die Abfrage betreffen. Die bevorzugten
Ausführungsbeispiele schließen in dem Ergebnis der CPU-Zyklen
jedoch auch alle Zwischenfunktionen ein, welche die Abfrage
betreffen. In diesem Szenario addiert eine Abfrage die CPU-
Zyklen für alle Funktionen, die sich auf einem Pfad befinden,
der die Abfrage betrifft. Die Abfrage C2 → Platzhalter → E hat
also die Addition der CPU-Zyklen von 1050, 1060, 1070, 1080
und 1090 zum Ergebnis, woraus sich 112 CPU-Zyklen für diese
Abfrage ergeben. Diese und andere mathematische Abweichungen
der bevorzugten Ausführungsbeispiele liegen ausdrücklich in
ihrem Geltungsbereich.
Das einfache Programm in den FIGS. 4-9 und die einfachen
Abfragen in Fig. 11 wurden dargestellt, um die Methode der
bevorzugten Ausführungsbeispiele zu veranschaulichen.
Natürlich sind die meisten Computerprogramme wesentlich
komplizierter, die Anzahl der Abfragen kann sehr groß und die
Abfragen können äußerst komplex sein. Anhand des hier
dargestellten vereinfachten Beispiels kann ein Fachmann jedoch
die hierin beschriebenen Methoden auf verschiedene Arten und
Größen von Computerprogrammen und Abfragen anwenden.
Die hierin beschriebene Vorrichtung und die beschriebenen
Methoden bieten einem Benutzer die Möglichkeit, die Leistung
eines Computerprogramms in einer bisher nicht möglichen Form
zu analysieren. Bei den bekannten Leistungsanalyse-Tools wird
geprüft, ob ein einzelnes Codesegment einen Leistungsengpaß
dar. Die vorliegende Erfindung dagegen ermöglicht die
Spezifikation von ad-hoc-Abfragen, mit denen Pfade ausfindig
gemacht werden können, die mehrere Codesegmente in dem
Computerprogramm betreffen, wobei der Engpaß nicht durch ein
einzelnes Codesegment in dem Pfad, sondern durch die
Wechselwirkung der Codesegmente untereinander entstehen kann.
Ein Fachmann wird anerkennen, dass innerhalb des
Geltungsbereichs der vorliegenden Erfindung viele Variationen
möglich sind. Während die Erfindung insbesondere unter
Bezugnahme auf bevorzugte Ausführungsbeispiele dargestellt und
beschrieben wurde, dürfte einem Fachmann klar sein, dass diese
und andere Änderungen in Form und Detail daran vorgenommen
werden können, ohne vom Prinzip und vom Umfang der Erfindung
abzuweichen.
Claims (24)
1. Eine Vorrichtung, umfassend:
- A) mindestens einen Prozessor;
- B) einen Speicher, der mit dem mindestens einen Prozessor gekoppelt ist;
- C) ein in dem Speicher gespeichertes Computerprogramm, wobei das Computerprogramm eine Vielzahl von Codesegmenten umfasst; und
- D) einen in dem Speicher gespeicherten
Leistungsanalysator für ein Computerprogramm, der
folgendes umfasst:
einen Logger, der die Daten für das Computerprogramm protokolliert, während das Computerprogramm entsprechend einem vorher festgelegten Satz von Programmausführungsbedingungen abläuft; und
ein Abfrage-Tool, mit dem ein Benutzer mindestens eine Abfrage der protokollierten Leistungsdaten festlegen kann, und das aus den protokollierten Leistungsdaten Informationen sammelt, um die mindestens eine Abfrage zu beantworten.
2. Die Vorrichtung nach Anspruch 1, bei der die
protokollierten Leistungsdaten eine Reihe von
Prozessorzyklen zur Ausführung eines jeden Codesegments
umfassen.
3. Die Vorrichtung nach Anspruch 1, bei der der Logger
Leistungsdaten für jedes Codesegment in dem
Computerprogramm protokolliert.
4. Die Vorrichtung nach Anspruch 3, bei der die
Leistungsdaten für das ausgewählte Codesegment folgendes
umfassen:
- 1. Ausführungszeit für das ausgewählte Codesegment; und
- 2. gegebenenfalls alle Codesegmente, die während der Ausführung des ausgewählten Codesegments aufgerufen wurden.
5. Die Vorrichtung nach Anspruch 1, weiter umfassend einen
Graphikprogrammgenerator, der eine graphische Darstellung
der Leistungsdaten erzeugt, die Informationen über den
Programmablauf zwischen einzelnen Codesegmenten und die
Ausführungszeit eines jeden Codesegments umfasst.
6. Die Vorrichtung nach Anspruch 5, weiter umfassend einen
Programmwiederholungsmechanismus, der die graphische
Darstellung der Leistungsdaten schrittweise durchläuft
und Informationen über die Leistungsdaten sammelt, um die
mindestens eine Abfrage zu beantworten.
7. Eine Vorrichtung, folgendes umfassend:
- 1. mindestens einen Prozessor;
- 2. einen Speicher, der mit dem mindestens einen Prozessor gekoppelt ist;
- 3. ein in dem Speicher gespeichertes Computerprogramm, wobei das Computerprogramm eine Vielzahl von Codesegmenten umfasst;
- 4. ein in dem Speicher gespeicherter
Leistungsanalysator für ein Computerprogramm,
folgendes umfassend:
- 1. einen Codesegment-Logger, der die Leistungsdaten für jedes Codesegment in dem Computerprogramm protokolliert, während das Computerprogramm entsprechend einer vordefinierten Gruppe von Programmausführungsbedingungen abläuft, wobei die Leistungsdaten für ein ausgewähltes Codesegment folgendes umfassen:
- 2. die Ausführungszeit für das ausgewählte Codesegment; und
- 3. gegebenenfalls Informationen über alle Codesegmente, die während der Ausführung des ausgewählten Codesegments aufgerufen wurden;
- 4. einen Graphikprogrammgenerator, der eine graphische Darstellung der Leistungsdaten erzeugt;
- 5. ein Abfrage-Tool, mit dem ein Benutzer mindestens eine Abfrage der protokollierten Leistungsdaten durchführen kann; und
- 6. einen Programmwiederholungsmechanismus, der schrittweise die graphische Darstellung der Leistungsdaten abarbeitet und Informationen über die Leistungsdaten sammelt, um mindestens eine Abfrage zu beantworten.
8. Eine Vorrichtung, folgendes umfassend:
ein in einem Speicher gespeichertes Computerprogramm, wobei das Computerprogramm eine Vielzahl von Codesegmenten umfasst;
Mittel zum Protokollieren von Leistungsdaten für jedes Codesegment in dem Computerprogramm, während das Computerprogramm entsprechend einem vordefinierten Satz von Programmausführungsbedingungen abläuft;
Mittel zum Formulieren einer Abfrage; und
Mittel zum Sammeln von Daten, welche die Abfrage beantworten, aus den protokollierten Leistungsdaten.
ein in einem Speicher gespeichertes Computerprogramm, wobei das Computerprogramm eine Vielzahl von Codesegmenten umfasst;
Mittel zum Protokollieren von Leistungsdaten für jedes Codesegment in dem Computerprogramm, während das Computerprogramm entsprechend einem vordefinierten Satz von Programmausführungsbedingungen abläuft;
Mittel zum Formulieren einer Abfrage; und
Mittel zum Sammeln von Daten, welche die Abfrage beantworten, aus den protokollierten Leistungsdaten.
9. Eine Methode zum Analysieren der Leistung eines
Computerprogramms, wobei die Methode folgende Schritte
umfasst:
- 1. Protokollieren der Leistungsdaten für jedes Codesegment in dem Computerprogramm, während das Computerprogramm unter einem vordefinierten Satz von Programmausführungsbedingungen abläuft;
- 2. Formulieren einer Abfrage; und
- 3. Sammeln von Informationen aus den protokollierten Leistungsdaten, welche die Abfrage beantworten.
10. Die Methode nach Anspruch 9, weiter umfassend den Schritt
des Aufbauens einer graphischen Darstellung der
Leistungsdaten, welche die Informationen über den
Programmablauf zwischen den Codesegmenten und die
Ausführungszeit für jedes Codesegment umfassen.
11. Die Methode nach Anspruch 10, bei der Schritt (3) das
Durchlaufen der graphischen Darstellung der
Leistungsdaten und das Sammeln von Informationen aus den
Leistungsdaten umfasst, um die mindestens eine Abfrage zu
beantworten, durch Wiederholen mindestens einer
Ausführungssequenz von Codesegmenten und Sammeln von
Informationen zur Beantwortung der Abfrage, während jedes
Codesegment in der Ausführungssequenz wiederholt wird.
12. Die Methode nach Anspruch 9, bei der der Schritt des
Formulierens einer Abfrage die Definition einer ad-hoc-
Abfrage durch einen Benutzer umfasst.
13. Eine Methode zum Analysieren der Leistung eines
Computerprogramms, das eine Vielzahl von Codesegmenten
umfasst, wobei die Methode folgende Schritte umfasst:
- 1. Protokollieren der Leistungsdaten für jedes
Codesegment in dem Computerprogramm, während das
Computerprogramm entsprechend einem vordefinierten
Satz von Programmausführungsbedingungen abläuft,
wobei die Leistungsdaten für ein ausgewähltes
Codesegment folgendes umfassen:
- 1. Ausführungszeit für das ausgewählte Codesegment; und
- 2. gegebenenfalls alle Codesegmente, die während der Ausführung des ausgewählten Codesegments aufgerufen wurden;
- 2. Erzeugen einer graphischen Darstellung der Leistungsdaten;
- 3. Definition mindestens einer Abfrage für die protokollierten Leistungsdaten; und
- 4. schrittweises Abarbeiten der graphischen Darstellung der Leistungsdaten und Sammeln von Informationen über die Leistungsdaten, um mindestens eine Abfrage zu beantworten.
14. Ein Programmprodukt, folgendes umfassend:
- A) einen Leistungsanalysator für ein Computerprogramm,
folgendes umfassend:
einen Logger, der Leistungsdaten für ein Computerprogramm protokolliert, das eine Vielzahl von Codesegmenten umfasst, während das Computerprogramm entsprechend einem vordefinierten Satz von Programmausführungsbedingungen abläuft;
ein Abfrage-Tool, das einem Benutzer die Definition mindestens einer Abfrage für die protokollierten Leistungsdaten ermöglicht, und das aus den protokollierten Leistungsdaten Informationen sammelt, um die mindestens eine Abfrage zu beantworten; und - B) signaltragende Medien, welche den Leistungsanalysator für das Computerprogramm tragen.
15. Das Programmprodukt nach Anspruch 14, bei dem die
signaltragenden Medien Aufzeichnungsmedien umfassen.
16. Das Programmprodukt nach Anspruch 14, bei dem die
signaltragenden Medien Übertragungsmedien umfassen.
17. Das Programmprodukt nach Anspruch 14, bei dem die
protokollierten Leistungsdaten eine Reihe von für die
Ausführung eines jeden Codesegments erforderlichen
Prozessorzyklen umfassen.
18. Das Programmprodukt nach Anspruch 14, bei dem der Logger
die Leistungsdaten für jedes Codesegment in dem
Computerprogramm protokolliert.
19. Das Programmprodukt nach Anspruch 18, bei dem die
Leistungsdaten für ein ausgewähltes Codesegment folgendes
umfassen:
- 1. die Ausführungszeit für das ausgewählte Codesegment; und
- 2. gegebenenfalls Informationen über alle Codesegmente, die während der Ausführung des ausgewählten Codesegments aufgerufen wurden.
20. Das Programmprodukt nach Anspruch 14, weiter umfassend
einen Graphikprogrammgenerator, der eine graphische
Darstellung der Leistungsdaten erzeugt und der
Informationen über den Programmablauf zwischen einzelnen
Codesegmenten und die Ausführungszeit für jedes
Codesegment umfasst.
21. Das Programmprodukt nach Anspruch 14, weiter umfassend
einen Programmwiederholungsmechanismus, der schrittweise
die graphische Darstellung der Leistungsdaten durchläuft
und Informationen über die Leistungsdaten sammelt, um die
mindestens eine Abfrage zu beantworten.
22. Ein Programmprodukt, folgendes umfassend:
- A) einen Leistungsanalysator für ein Computerprogramm,
folgendes umfassend:
- 1. einen Codesegment-Logger, der die Leistungsdaten für jedes Codesegment in dem Computerprogramm protokolliert, während das Computerprogramm entsprechend einem vordefinierten Satz von Programmausführungsbedingungen abläuft, wobei die Leistungsdaten für ein ausgewähltes Codesegment folgendes umfassen:
- 2. die Ausführungszeit für das ausgewählte Codesegment; und
- 3. gegebenenfalls Informationen über alle Codesegmente, die während der Ausführung des ausgewählten Codesegments aufgerufen wurden;
- 4. einen Graphikprogrammgenerator, der eine graphische Darstellung der Leistungsdaten erzeugt;
- 5. ein Abfrage-Tool, mit dem ein Benutzer mindestens eine Abfrage für die protokollierten Leistungsdaten definieren kann; und
- 6. einen Programmwiederholungsmechanismus, der die graphische Darstellung schrittweise durchläuft und Informationen über die Leistungsdaten sammelt, um die mindestens eine Abfrage zu beantworten; und
- B) signaltragende Medien, die den Leistungsanalysator für das Computerprogramm tragen.
23. Das Programmprodukt nach Anspruch 22, bei dem das
signaltragende Medium Aufzeichnungsmedien umfasst.
24. Das Programmprodukt nach Anspruch 22, bei dem das
signaltragende Medium Übertragungsmedien umfasst.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US390097 | 1999-09-03 | ||
US09/390,097 US6557167B1 (en) | 1999-09-03 | 1999-09-03 | Apparatus and method for analyzing performance of a computer program |
Publications (2)
Publication Number | Publication Date |
---|---|
DE10039538A1 true DE10039538A1 (de) | 2001-03-15 |
DE10039538B4 DE10039538B4 (de) | 2005-01-27 |
Family
ID=23541039
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE10039538A Expired - Lifetime DE10039538B4 (de) | 1999-09-03 | 2000-08-11 | Vorrichtung und Verfahren zum Analysieren der Leistung eines Computerprogramms |
Country Status (2)
Country | Link |
---|---|
US (1) | US6557167B1 (de) |
DE (1) | DE10039538B4 (de) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102004014885A1 (de) * | 2004-03-26 | 2005-11-03 | Giesecke & Devrient Gmbh | Verfahren zur Optimierung eines Programms eines tragbaren Datenträgers |
Families Citing this family (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2378025A (en) * | 2000-05-04 | 2003-01-29 | Gen Electric Capital Corp | Methods and systems for compliance program assessment |
DE10054542A1 (de) * | 2000-11-03 | 2002-06-20 | Siemens Ag | Prüfverfahren und Prüfvorrichtung zur Inbetriebnahme von mittels einer Programmlogik gesteuerten Systemen |
US6996558B2 (en) | 2002-02-26 | 2006-02-07 | International Business Machines Corporation | Application portability and extensibility through database schema and query abstraction |
US8732675B2 (en) * | 2003-06-23 | 2014-05-20 | Broadcom Corporation | Operational analysis system for a communication device |
US7533371B1 (en) * | 2003-09-22 | 2009-05-12 | Microsoft Corporation | User interface for facilitating performance analysis for processing |
US7095416B1 (en) * | 2003-09-22 | 2006-08-22 | Microsoft Corporation | Facilitating performance analysis for processing |
US7900133B2 (en) | 2003-12-09 | 2011-03-01 | International Business Machines Corporation | Annotation structure type determination |
US7496900B2 (en) * | 2004-02-12 | 2009-02-24 | International Business Machines Corporation | Method for automatic detection of build regressions |
US8266595B2 (en) | 2004-02-12 | 2012-09-11 | International Business Machines Corporation | Removal of asynchronous events in complex application performance analysis |
US7480899B2 (en) * | 2004-03-22 | 2009-01-20 | International Business Machines Corporation | Method and apparatus for autonomic test case feedback using hardware assistance for code coverage |
US7444332B2 (en) * | 2005-11-10 | 2008-10-28 | International Business Machines Corporation | Strict validation of inference rule based on abstraction environment |
US7440945B2 (en) | 2005-11-10 | 2008-10-21 | International Business Machines Corporation | Dynamic discovery of abstract rule set required inputs |
WO2007067894A2 (en) * | 2005-12-05 | 2007-06-14 | National Instruments Corporation | Implementing a design flow for a programmable hardware element that includes or is coupled to a processor |
WO2007145903A2 (en) | 2006-06-05 | 2007-12-21 | Acumem Ab | System for and method of capturing application characteristics data from a computer system and modeling target system |
US20080007563A1 (en) * | 2006-07-10 | 2008-01-10 | Microsoft Corporation | Pixel history for a graphics application |
US8443341B2 (en) * | 2006-11-09 | 2013-05-14 | Rogue Wave Software, Inc. | System for and method of capturing application characteristics data from a computer system and modeling target system |
US8214807B2 (en) * | 2007-01-10 | 2012-07-03 | International Business Machines Corporation | Code path tracking |
WO2009022239A2 (en) * | 2007-03-26 | 2009-02-19 | Acumem Ab | System for and method of capturing performance characteristics data from a computer system and modeling target system performance |
US8271959B2 (en) * | 2008-04-27 | 2012-09-18 | International Business Machines Corporation | Detecting irregular performing code within computer programs |
US8756564B2 (en) | 2009-05-29 | 2014-06-17 | International Business Machines Corporation | Techniques for providing environmental impact information associated with code |
US8555259B2 (en) * | 2009-12-04 | 2013-10-08 | International Business Machines Corporation | Verifying function performance based on predefined count ranges |
US8887077B2 (en) | 2011-11-21 | 2014-11-11 | Microsoft Corporation | Synchronized graphical and tabular performance data display |
US20130249917A1 (en) * | 2012-03-26 | 2013-09-26 | Microsoft Corporation | Profile data visualization |
US8955115B2 (en) * | 2012-07-06 | 2015-02-10 | Sap Se | Automatic generation of security checks |
US9729671B2 (en) * | 2014-10-05 | 2017-08-08 | YScope Inc. | Systems and processes for computer log analysis |
EP3898373A4 (de) * | 2018-12-19 | 2023-01-11 | Zoox, Inc. | Sicherer systembetrieb unter verwendung von latenzbestimmungen und bestimmungen der cpu-nutzung |
US11281214B2 (en) | 2018-12-19 | 2022-03-22 | Zoox, Inc. | Safe system operation using CPU usage information |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH02199548A (ja) * | 1988-11-09 | 1990-08-07 | Asea Brown Boveri Ag | 電算機系で作成されるオブジエクト・プログラムの時間経過を観察する方法とこの方法を実行する観測器具 |
US5485574A (en) * | 1993-11-04 | 1996-01-16 | Microsoft Corporation | Operating system based performance monitoring of programs |
JP3472026B2 (ja) * | 1996-03-26 | 2003-12-02 | 富士通株式会社 | ログ情報採取解析装置 |
US6330008B1 (en) * | 1997-02-24 | 2001-12-11 | Torrent Systems, Inc. | Apparatuses and methods for monitoring performance of parallel computing |
US5835705A (en) * | 1997-03-11 | 1998-11-10 | International Business Machines Corporation | Method and system for performance per-thread monitoring in a multithreaded processor |
US6233531B1 (en) * | 1997-12-19 | 2001-05-15 | Advanced Micro Devices, Inc. | Apparatus and method for monitoring the performance of a microprocessor |
US6199199B1 (en) * | 1998-09-16 | 2001-03-06 | International Business Machines Corporation | Presentation of visual program performance data |
US6256773B1 (en) * | 1999-08-31 | 2001-07-03 | Accenture Llp | System, method and article of manufacture for configuration management in a development architecture framework |
-
1999
- 1999-09-03 US US09/390,097 patent/US6557167B1/en not_active Expired - Lifetime
-
2000
- 2000-08-11 DE DE10039538A patent/DE10039538B4/de not_active Expired - Lifetime
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102004014885A1 (de) * | 2004-03-26 | 2005-11-03 | Giesecke & Devrient Gmbh | Verfahren zur Optimierung eines Programms eines tragbaren Datenträgers |
DE102004014885B4 (de) * | 2004-03-26 | 2016-04-14 | Giesecke & Devrient Gmbh | Verfahren zur Optimierung eines Programms eines tragbaren Datenträgers |
Also Published As
Publication number | Publication date |
---|---|
DE10039538B4 (de) | 2005-01-27 |
US6557167B1 (en) | 2003-04-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE10039538B4 (de) | Vorrichtung und Verfahren zum Analysieren der Leistung eines Computerprogramms | |
DE69021659T2 (de) | Verfahren und Vorrichtung zur reihenweisen Parallelprogrammfehlersuche. | |
DE69029983T2 (de) | Leistungsverbesserungsgerät für auf Regeln beruhendes Expertensystem | |
DE19781804B4 (de) | Vorrichtung zur Simulation einer Echtzeit-Prozesssteuerung | |
DE69831732T2 (de) | Verfahren und gerät zum korrigieren von fehlern in einem rechnersystem | |
DE69031758T2 (de) | Verfahren zur Organisation von und zum Zugriff auf Produkt beschreibenden Daten in Zusammenhang mit einem technischen Prozess | |
DE112016002298T5 (de) | Vorabruf von gewichten zur verwendung in einem neuronalen netzwerkprozessor | |
DE2244402A1 (de) | Datenverarbeitungsanlage | |
DE102013207049A1 (de) | Überwachen der Datenstrompufferung zur Optimierung der Operatorverarbeitung | |
DE60219821T2 (de) | Verfahren und gerät zum wiedergewinnen von zeitreihedaten, die mit einer aktivität in beziehung stehen | |
DE112013000966T5 (de) | Vorrichtung, Programm und Verfahren zum Clustern einer Vielzahl von Dokumenten | |
DE60303413T2 (de) | Verfahren und computersystem zum reduzieren von ausführungszeiten bei der materialbedarfsplanung | |
DE102020211679A1 (de) | Computer-implementiertes system und verfahren mit einem digitalen zwilling und einer graphen-basierten struktur | |
DE112018002316T5 (de) | Codeabdeckungsverfolgung für ein mikrocontroller-programm | |
DE112013000751T5 (de) | Datenverarbeitung, Datensammlung | |
DE19513960A1 (de) | Abbildung eines Graphen in einen Speicher | |
DE102016007651B4 (de) | Numerische Steuerung mit Funktion zur automatischen Auswahl eines Speicherungsziels für ein Bearbeitungsprogramm | |
DE60217729T2 (de) | Verfahren zum erkennen eines elektronischen geräts in einem mehrfachsteuersystem | |
DE4422637A1 (de) | Rechnersystem und Verfahren zum Problemlösen | |
EP0838054A1 (de) | Verfahren und steuereinrichtung für eine graphische steuerung von abläufen in einem netzwerkmanagementsystem | |
WO2003094093A2 (de) | Vergleich von verarbeitungsprotokollen | |
DE10056825C2 (de) | Verfahren, Vorrichtung und Computerprogramm zum Erzeugen eines Zufallstestcodes | |
DE19963123B4 (de) | Analytisches Informationssystem | |
DE10393809B4 (de) | Computer-implementiertes Verfahren zum Verarbeiten von Information, die zwischen einem Client und einem Server ausgetauscht wird | |
DE112018006331B4 (de) | Testfallgenerierungsvorrichtung, Testfallgenerierungsverfahren und Testfallgenerierungsprogramm |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8364 | No opposition during term of opposition | ||
8320 | Willingness to grant licences declared (paragraph 23) | ||
R071 | Expiry of right |