WO2008113681A1

WO2008113681A1 - Verfahren zum rechnergestützten bestimmen des optimierungspotentials eines softwaresystems

Info

Publication number: WO2008113681A1
Application number: PCT/EP2008/052638
Authority: WO
Inventors: Florian Mangold; Michael PÖNITSCH; Bernhard Kempter
Original assignee: Siemens Aktiengesellschaft
Priority date: 2007-03-20
Filing date: 2008-03-05
Publication date: 2008-09-25
Also published as: US8527951B2; US20100095275A1

Abstract

Es wird ein Verfahren zum rechnergestützten Bestimmen des Optimierungspotentials eines Softwaresystems beschrieben, das eine Vielzahl an Modulen (A, B, C) umfasst, die beim Ablauf des Softwaresystems zumindest teilweise miteinander interagieren können. Von der Vielzahl an Modulen (A, B, C) wird zumindest ein zu untersuchendes Modul (B) bestimmt, welches hinsichtlich der Auswirkung einer Optimierung des zumindest einen zu untersuchenden Moduls (B) auf den Gesamtressourcenverbrauch des Softwaresystems untersucht werden soll. Ein jeweiliger Ressourcenverbrauch eines oder mehrerer oder aller nicht zu untersuchender Module (A, C) der Vielzahl an Modulen (A, B, C) wird gemäss zumindest einem vorgegebenen Kriterium variiert, wodurch ein modifiziertes Softwaresystem erhalten wird. Der Gesamtressourcenverbrauch des modifizierten Softwaresystems wird unter Berücksichtigung der Variation der nicht zu untersuchenden Module (A, C) ermittelt. Schliesslich wird der ermittelte Gesamtressourcenverbrauch des modifizierten Softwaresystems mit dem Gesamtressourcenverbrauch des unmodifizierten Softwaresystems verglichen.

Description

Beschreibung

Verfahren zum rechnergestützten Bestimmen des Optimierungspotentials eines Softwaresystems

Die Erfindung betrifft ein Verfahren zum rechnergestützten Bestimmen des Optimierungspotentials eines Softwaresystems, das eine Vielzahl an Modulen umfasst, die beim Ablauf des Softwaresystems zumindest teilweise miteinander interagieren können.

Komplexe Softwaresysteme, die eine Vielzahl an unterschiedlichen und teilweise interagierenden Modulen umfassen, werden häufig von einer Mehrzahl an Programmierern erstellt. Häufig tritt hierbei das Problem auf, dass die Performanz des Softwaresystems nicht zufriedenstellend ist. Da das Verständnis eines komplexen Softwaresystems nicht einfach ist, stellt sich häufig das Problem, welches oder welche Module des Softwaresystems optimiert werden müssen, um eine Verbesserung der Performanz oder einen verringerten Ressourcenverbrauch, wie z.B. Speicherbedarf, herbeiführen zu können. Es ist zum Beispiel möglich, das oder diejenigen Module zu identifizieren, welche einen Ressourcenengpass, ein Performanzproblem oder einen Flaschenhals darstellen. In der Regel kann jedoch nicht abgeschätzt werden, wie sich die Performanz des Softwaresystems oder der Gesamtressourcenverbrauch des Ressourcensystems entwickeln, wenn das oder die betreffenden Module optimiert werden .

Profilerdaten können in einfachen Softwaresystemen, insbesondere sog. Single-Threaded-Systemen mit Methoden ohne Seiteneffekte dazu verwendet werden, um eine Abschätzung zu gewinnen, inwieweit sich eine Optimierung des Softwaresystems auf dessen Laufzeiteigenschaften auswirkt. Ein Nachteil besteht jedoch darin, dass dies lediglich für einfache Systeme, wie die Single-Threaded-Systeme möglich ist. Insbesondere können Seiteneffekte nicht berücksichtigt werden. Eine gängige Programmierpraxis zur Optimierung des Softwaresystems ist es, Module, welche Ursache für das Performanz- problem sein könnten, auszukommentieren oder zu simulieren und damit ihren Anteil an der Performanz abzuschätzen. Dieses Vorgehen ist jedoch in komplexen Systemen durch funktionale Abhängigkeiten im Softwarecode nicht möglich.

Weiterhin bekannt ist das sog. „Snapshot-Differencing" . Bei diesem Verfahren kann die Volatilität des Softwarecodes durch die Herstellung eines Zustandsbilds (Snapshot) des unveränderten und eines veränderten Softwarecodes vorgenommen werden. Diese Vorgehensweise erfordert jedoch ein unter Umständen sehr aufwendiges Reengineering des zu untersuchenden Softwaresystems.

Es ist daher Aufgabe der vorliegenden Erfindung, ein Verfahren zum rechnergestützten Bestimmen des Optimierungspotentials eines Softwaresystems anzugeben, welches auf einfache Weise realisierbar ist und sich auch bei komplexen Softwaresystemen zuverlässig einsetzen lässt.

Diese Aufgabe wird durch die Merkmale der unabhängigen Patentansprüche gelöst. Vorteilhafte Ausführungsformen finden sich in den abhängigen Patentansprüchen wieder.

Das erfindungsgemäße Verfahren zum rechnergestützten Bestimmen des Optimierungspotentials eines Softwaresystems, das eine Vielzahl an Modulen umfasst, die beim Ablauf des Software- Systems zumindest teilweise miteinander interagieren können, umfasst die folgenden Schritte: Von der Vielzahl an Modulen wird zumindest ein zu untersuchendes Modul bestimmt, welches hinsichtlich der Auswirkung einer Optimierung des zumindest einen zu untersuchenden Moduls auf den Gesamtressourcen- verbrauch des Softwaresystems untersucht werden soll. Ein jeweiliger Ressourcenverbrauch eines oder mehrerer oder aller nicht zu untersuchender Module der Vielzahl an Modulen wird gemäß zumindest einem vorgegebenen Kriterium variiert, wodurch ein modifiziertes Softwaresystem erhalten wird. Der Gesamtressourcenverbrauch des modifizierten Softwaresystems wird unter Berücksichtigung der Variation der nicht zu unter- suchenden Module ermittelt. Schließlich wird der ermittelte Gesamtressourcenverbrauch des modifizierten Softwaresystems mit dem Gesamtressourcenverbrauch des unmodifizierten Softwaresystems verglichen.

Das der Erfindung zugrunde liegende Prinzip besteht darin, den Ressourcenverbrauch aller ressourcenverbrauchenden Teile des Softwaresystems künstlich zu erhöhen, so dass die zu untersuchenden Systemteile im Ressourcenverbrauch verkürzt erscheinen. Wird eines oder werden mehrere oder alle Module z.B. verlangsamt, so kann dadurch ein Gesamtsystem z.B. halb so schnell simuliert werden. Dies ist vergleichbar mit einem Throttling. Wenn beim Erhöhen des Ressourcenverbrauches der Module des Gesamtsystems ein Modul oder mehrere Module nicht in ihrem Ressourcenverbrauch verändert werden, so ist dieses oder diese Module im Vergleich zu dem Gesamtsystem relativ verkürzt. Durch dieses Vorgehen erscheint das zu untersuchende Modul (die zu untersuchenden Module) performanter oder der Ressourcenverbrauch scheint geringer, es erfolgt quasi eine optimierte Simulation.

Die Variation des Ressourcenverbrauchs ist zweckmäßigerweise eine Vergrößerung des Ressourcenverbrauchs. Die Vergrößerung des Ressourcenverbrauchs kann beispielsweise bei der Laufzeit eine Prolongation, d.h. eine Verlängerung der Laufzeit, eines betreffenden Moduls sein.

Gemäß einer weiteren Ausführungsform ist im Falle eines deterministischen Softwaresystems das vorgegebene Kriterium ein Faktor, um den der Ressourcenverbrauch der nicht zu untersu- chenden Module variiert wird. Dabei kann für sämtliche der nicht zu untersuchenden Module ein gleicher Faktor gewählt werden. Alternativ können für die nicht zu untersuchenden Module unterschiedliche Faktoren gewählt werden.

Gemäß einer weiteren Ausführungsform ist im Falle eines nicht deterministischen Softwaresystems das vorgegebene Kriterium ein jeweiliger Faktor für jedes der nicht zu untersuchenden Module, der sich aus der Multiplikation eines oder eines jeweiligen Optimierungsfaktors mit einem jeweils für das betreffende Modul ermittelten Ressourcenverbrauch, insbeson- dere der Laufzeit, ergibt. Dabei kann weiter vorgesehen sein, dass der für ein betreffendes Modul ermittelte, variierte Ressourcenverbrauch, insbesondere die Laufzeit, an aufrufende Module des Softwaresystems übertragen und bei der Ermittlung des variierten Ressourcenverbrauchs eines aufrufenden Moduls berücksichtigt wird.

Es ist ferner zweckmäßig, wenn bei der Ermittlung des Gesamtressourcenverbrauchs des modifizierten Softwaresystems die Messergebnisse der nicht zu berücksichtigenden Module nor- miert werden. Hierdurch wird die Vergleichbarkeit eines nicht modifizierten Softwaresystems mit einem modifizierten Softwaresystem ermöglicht. Hierdurch kann das Potential einer Optimierung eines oder mehrerer zu untersuchender Module auf einfache Weise eruiert werden.

Eine weitere Ausführungsform sieht vor, die Schritte des erfindungsgemäßen Verfahrens mit unterschiedlichen Variationen der nicht zu untersuchenden Module wiederholt auszuführen. Hierdurch kann eine Aussage darüber getroffen werden, um wel- chen Faktor ein zu untersuchendes Modul verbessert werden sollte, um eine größtmögliche Optimierung des Gesamtressourcenverbrauchs zu erhalten.

Von der Erfindung ist ferner ein Computerprogrammprodukt um- fasst, das direkt in den internen Speicher eines digitalen

Computers geladen werden kann und Softwarecodeabschnitte um- fasst, mit denen die Schritte des beschriebenen Verfahrens ausgeführt werden, wenn das Produkt auf einem Computer läuft.

Die Erfindung wird nachfolgend näher anhand der Figuren er- läutert. Es zeigen:

Fig. 1 ein erstes Ausführungsbeispiel, das das erfindungsgemäße Verfahren anhand eines Single-Threaded- Systems erläutert,

Fig. 2 ein weiteres Ausführungsbeispiel, das das Verfahren der Erfindung an einem Multi-Thread-System erläutert, und

Fig. 3 eine Darstellung, welche die Gesamtperformanz in

Abhängigkeit unterschiedlicher Variationen der untersuchten Softwaresystems darstellt.

Die der Erfindung zugrunde liegende Idee besteht darin, das Optimierungspotential eines oder mehrerer Module hinsichtlich der Auswirkung auf den Gesamtressourcenverbrauch des Softwaresystems zu simulieren. Dies bedeutet, dass das zu untersuchende Modul selbst nicht optimiert wird, um die Auswirkung dieser Optimierung auf das Gesamtsystem zu untersuchen. Viel- mehr werden zumindest einige oder bevorzugt alle der nicht zu untersuchenden Module des Softwaresystems in ihrem Ressourcenverbrauch verschlechtert. So kann beispielsweise die Laufzeit eines jeweiligen nicht zu untersuchenden Moduls künstlich verlängert werden. In einer Simulation verhält sich das Softwaresystem deshalb langsamer oder der Ressourcenbedarf vergrößert, im Vergleich zu einem unmodifizierten Softwaresystem. Das hierbei zugrunde liegende Prinzip besteht darin, dass beim Prolongieren der nicht zu untersuchenden Module des Softwaresystems das zu untersuchende Modul, das nicht prolon- giert wird, im Vergleich zu dem Gesamtsystem relativ verkürzt erscheint. Werden die Ergebnisse einer Laufzeitmessung des Gesamtsystems durch den gewählten Verlängerungsfaktor geteilt (normiert) , so erhält man Werte einer Laufzeitmessung, bei dem das Modul so performant erscheint oder es den Eindruck eines geringeren Ressourcenverbrauchs macht, wie es simuliert wurde. Durch dieses Verfahren erscheint das zu untersuchende Modul performanter bzw. der Ressourcenverbrauch geringer, es wird quasi optimiert simuliert.

Die grundlegende Idee besteht darin, den Ressourcenverbrauch der ressourcenverbrauchenden Module des Softwaresystems künstlich zu erhöhen, so dass die zu untersuchenden Module verkürzt erscheinen. Idealerweise wird im Rahmen der optimierten Simulation ein Modul untersucht, während alle anderen nicht zu untersuchenden Module des Softwaresystems variiert, das heißt deren Ressourcenverbrauch erhöht werden. Denkbar ist auch, gleichzeitig mehrere Module zu untersuchen. Ebenso vorstellbar ist, den Ressourcenverbrauch von nicht allen zu untersuchenden Modulen zu erhöhen, sondern lediglich einen Teil davon.

In Fig. 1 ist ein erstes Ausführungsbeispiel abgebildet, bei dem das Softwaresystem aus zwei Modulen A, B bestehen soll, welche in einem einzigen Thread (Ausführungsstrang) angeordnet sind. Beide Module A, B weisen eine Laufzeit von zehn Einheiten auf. Eine Einheit kann beispielsweise eine Zeitein- heit, Millisekunden, Sekunden und dergleichen sein. Das schraffierte Modul B stellt das zu untersuchende bzw. optimierende Modul dar. Entsprechend der vorher erläuterten Beschreibung, wird Modul A in seinem Ressourcenverbrauch beispielhaft verdoppelt. Der hierbei gewählte Faktor kann will- kürlich gewählt werden. Betrachtet man nun in der unteren

Hälfte der Fig. 1 die Laufzeiten des Softwaresystems, so erkennt man, dass Modul B relativ verkürzt erscheint. Während in der linken unteren Hälfte das Modul A 20 Einheiten und das Modul B (unverändert) zehn Einheiten aufweist, ist in der rechten unteren Hälfte eine Normierung um den gewählten Verlängerungsfaktor 2 vorgenommen worden, so dass das nicht zu untersuchende Modul A wiederum den Ursprungswert von zehn Einheiten aufweist. In entsprechender Weise hat sich die Laufzeit des zu untersuchenden Moduls B auf fünf Einheiten halbiert. Normierung bedeutet somit, dass die absoluten Werte durch den Optimierungsfaktor, hier 2, geteilt werden. Die Si- mulation der Optimierung zeigt, dass bei einem Reengineering des Moduls B die Gesamtlaufzeit des Softwaresystems um fünf Einheiten reduzierbar ist.

In Fig. 2 ist ein weiteres Ausführungsbeispiel dargestellt, wobei das Softwaresystem drei Module A, B, C aufweist. Das Softwaresystem ist ein sog. nebenläufiges System, welches zwei Treads umfasst, die parallel zueinander ablaufen. Beide Threads (der linke Thread umfasst die Module A und B, der rechte Thread umfasst das Modul C) haben im Ausführungsbei- spiel dieselbe Laufzeit von 20 Einheiten. Es soll wiederum Modul B untersucht werden, während Module A und C nicht zu untersuchende Module darstellen. Die Untersuchung erfolgt dahingehend, ob ein Reengineering des Moduls B sinnvoll wäre, um das Gesamtsystem performanter zu gestalten.

Die Module B, C werden im Ausführungsbeispiel wiederum in ihrem Ressourcenverbrauch verdoppelt. Aus der unteren Darstellung der Fig. 2 geht ohne Weiteres hervor, dass durch die simulierte Optimierung der linke Thread nunmehr in viel kürze- rer Zeit fertig ist. Muss dieser Thread auf den rechten

Thread warten, so bedeutet dies, dass ein Reengineering keinen positiven Effekt auf das Softwaresystem haben wird.

Die Vorgehensweise der Implementierung des erfindungsgemäßen Verfahrens variiert in Abhängigkeit davon, ob das Softwaresystem deterministisch oder nicht deterministisch ist. Ein deterministisches Softwaresystem verhält sich bei jeder Ausführung gleich, dies bedeutet, dass Module ungefähr denselben Ressourcenverbrauch aufweisen, wenn diese wiederholt ausge- führt werden. In einem deterministischen Softwaresystem wird der Ressourcenverbrauch bei einer Ausführung des Systems gemessen. Nach der Ausführung wird für alle, bis auf die zu un- tersuchenden Systemteile künstlich der entsprechende Ressourcenverbrauch hinzugefügt. Die Messergebnisse werden in der oben beschriebenen Weise auf den künstlichen Ressourcenverbrauch angepasst, d.h. normiert. Hierdurch erscheinen die zu untersuchenden Module optimiert.

Ein nicht deterministisches System verhält sich nicht bei jeder Systemausführung gleich. Daher kann nicht aus Profilinginformationen ein künstlich zu addierender Ressourcen- verbrauch abgeschätzt werden. Deshalb wird bei einem nicht deterministischen Softwaresystem jedes Modul, das nicht hinsichtlich einer Optimierung untersucht werden soll, in einem automatisierten Prozess mit einer Funktion umschlossen, die den aktuellen Ressourcenverbrauch während des Ablaufs misst und anschließend den gemessenen Wert, multipliziert mit einem Optimierungsfaktor, als Ressourcenverbrauch hinzufügt. Nicht zu untersuchende Module werden nicht mit dieser Funktion umschlossen und erscheinen deshalb um den Optimierungsfaktor verkürzt .

Module mit einer höheren Stacktiefe werden zuerst in ihrem Ressourcenverbrauch variiert. Höhere Stacktiefe bedeutet, dass ein solches Modul von einem anderen Modul aufgerufen wird, welches selbst von einem weiteren Modul aufgerufen wer- den kann. Grund dafür, dass Methoden mit höherer Stacktiefe zuerst verlängert werden, ist, weil diese als erstes abgearbeitet werden und deshalb eine Laufzeit bereits gemessen wurde. Andererseits ist dieses Vorgehen zweckmäßig, um eine möglichst große Genauigkeit bei der Messung zu erhalten. Die ge- messenen Zeiten der Module mit höherer Stacktiefe werden an Module mit geringerer Stacktiefe, d.h. aufrufende Module, weitergegeben. Dies erfolgt, um zu verhindern, dass bereits verlängerte Module ein weiteres Mal verlängert werden. Dies bedeutet, dass von der Laufzeit eines zu verlängernden Modul- aufrufes die Zeiten für bereits prolongierte Aufrufe und deren Verlängerungen abgezogen werden müssen. In Fig. 3 ist das Ergebnis der optimierten Simulation für die Module A, B und C erkennbar. Über die X-Achse ist die Anzahl an Messungen aufgetragen. Über die Y-Achse ist die Laufzeit eines jeweiligen Moduls in Millisekunden aufgetragen. Die Si- mulation unterteilt sich in sechs Abschnitte I bis VI, wobei jeder Abschnitt ca. 25 Messungen umfasst. Im Abschnitt I wurde eine Anzahl an Messungen vorgenommen, in welchen die Module A und C keiner Variation unterworfen sind. Hieraus ergibt sich, dass die drei Module A, B, C eine im Wesentlichen glei- che Laufzeit aufweisen. In den Abschnitten II bis VI wurden jeweils eine Anzahl an Messungen vorgenommen, bei denen eine Prolongation um den Faktor 2 (Abschnitt II), Faktor 3 (Abschnitt III), usw., Faktor 6 (Abschnitt VI) vorgenommen wurde. Wie unschwer aus Fig. 3 zu erkennen ist, ergibt sich eine Prolongation der Module A und C, während das Modul B weiterhin die ursprünglich benötigte Zeit aufweist. Die mit G gekennzeichnete Linie stellt den Ressourcenverbrauch des gesamten Softwaresystems dar. Wie unschwer zu erkennen ist, nimmt der Gesamtressourcenverbrauch mit ansteigendem Variationsfak- tor ab. Dies bedeutet im Ausführungsbeispiel, der Gesamtressourcenverbrauch ist bei einer Prolongation der Module A und C um den Faktor 6 am Besten. Hieraus ergibt sich der Schluss, dass eine Optimierung des Moduls B zu einer Verbesserung des Gesamtressourcenverbrauchs des Softwaresystems führt, wobei sich der Gesamtressourcenverbrauch umso mehr verbessert, je stärker der Ressourcenverbrauch des Moduls B reduziert werden kann .

Im Folgenden wird noch eine Implementation des simulierten Optimieren von Systemteilen eines Systems beschrieben.

Das JAVA-Package verlängern ist eine Implementation mittels AspectJ, zum simulierten Optimieren von Systemteilen bezüglich ihrer Performanz. Der Pointcut Verlängern () gleicht alle Methoden des Softwaresystems ab (sog. Matching) , außer den

Programmfluss der zu simulierenden Methode und ihren dynamischen Kontext ( && ! cflow...) . Der Advice Verlängern () umschließt alle Methoden außer die zu simulierende Methode. In diesem Advice wird vor und nach dem Beenden der Methode die aktuelle Zeit gemessen (System. nanoTime ()) . Entsprechend dem Optimierungsfaktor wird die Zeit der Methode ohne Unteraufrufe durch einen künstlichen Ressourcenverbrauch verlängert.

Im Rahmen der beispielhaften Implementation steht eine Methode stellvertretend für ein Modul des Softwaresystems.

Ist der Optimierungsfaktor 2, d.h. die zu optimierende Methode soll doppelt so schnell simuliert werden, so wird die Zeit aller nicht zu optimierenden Methoden durch künstlichen Ressourcenverbrauch noch einmal hinzugefügt. Dies gilt jedoch nicht für die Zeit ihrer Unteraufrufe, diese werden durch das stackartige Abarbeiten bereits verlängert.

Der Programmcode der beispielhaften Simulation ist wie folgt:

package verlaengern ; Import trace . Trace2 ; public aspect Verlaengern { declare precedence : Trace2 , Verlaengern ;

pointcut Verlaengern ( ) : call ( * *.* ( .. ) ) && ! cflow simulierte Methode

&& ! within ( Trace2 ) ... weitere nicht simulierte Packa ges, Klassen etc.

Object around ( ) : Verlaengern () { long dt ; tvll.entry ( " " + Thread. currentThread () , "" + thisJoinPoint ) ; dt = System. nanoTime ( ) ; dt = dt / 1000 ; try { return proceed ( ) ; } finally {

// U m s c h l i e s s e n d e F u n k t i o n zeit messen dt = ( System. nanoTime ( ) / 1000 - d t ) ; long ausgeschlosseneZeit = tvll . exitTime ( " " +

Thread. currentThread ( ) , dt ) ;

// richtig verlängern ( eingeschlossene Zeit ist schon weg ) ! dt = dt - ausgeschlosseneZeit ; dt = dt * verlaengerungsfaktor ;

// ms , ns berechnen long ms = ( dt ) / 10001 ; int ns = ( int ) ( dt ) % 1000 ;

// .. und v e r l ä n g e r n ! // Einfügen des künstlichen Ressourcenverbrauchs,

Schleifen, sleep,

// arithmetische Operationen, etc...

// - ähnlich des Ressourcenverbrauchs der Methode/des Systems ;

; public static int verlaengerungsfaktor = 0 ; protected static ThreadVerlaengernLinkedList tvll ; public static void main ( String [ ] args ) {

// verlaengerungsfaktor bzw . Optimierungsfaktor set zen ! ! ! verlaengerungsfaktor = j ; // zu simulierendes System aufrufen program. vvl .maincall ( ) ;

} }

// H i l f s k i a s s e static { tvll = new ThreadVerlaengernLinkedList ( ) ;

} Eine verkettete Liste wird für ein korrektes Simulieren in asynchronen Softwaresystemen verwendet. In jedem Element der verketteten Liste werden die benötigten Informationen zum Si- mulieren für den entsprechenden Thread gespeichert. Ein beispielhaftes Listing ist wie folgt:

package verlaengern; Import java .math .Biginteger; Import java .util .LinkedList;

Import java . util . Listlterator;

public class ThreadVerlaengernLinkedList {

public LinkedList 11;

ThreadVerlaengernLinkedList () {

11 = new LinkedList () ; }

public synchronized void add (Object o) { ll.add(o) ; }

public synchronized long entry (String thread, String methode) { int index;

ThreadVerlaengern tl temp; index = this . getlndex (thread) ;

{ if (index >= 0) {

tl_ temp = (ThreadVerlaengern) 11 . get (index) ; tl temp . l ogtief e++ ; tl_temp. Stack .push (new Biginteger (" 0

") ) ; tl_temp .methodenStack .push (methode) ; return tl_temp . logtiefe; } eise { tl_temp = new ThreadVerlaengern (0, thread) ; tl_temp. Stack .push (new Biginteger (" 0 ") ) ; tl_temp .methodenStack .push (methode) ; this . add (tl_temp) ; return 0;

;

public synchronized long exitTime (String thread, long time) { int index; long rw;

ThreadVerlaengern tl_temp; Biginteger bi; // SUCHEN index = getlndex (thread) ;

// logtiefe VE R Ä N D E R N .'.'.' tl_temp = (ThreadVerlaengern) 11.get (index) ; tl_temp . logtiefe--; // return rw ;

if (tl_temp. logtiefe < 0) { tl temp. Stack . clear () ; tl_temp.methodenStack . clear () ; return 0; ; eise {

// aktuelle Methodenzeit holen // poppen bi = (Biginteger) tl_temp. Stack .pop ();

// Rückgabewert ist die aktuelle Methodenzeit

I I I rw = bi . longValue ( ) ; // und Zeit d a z u r e c h n e n ... bi = bi . add (new Biginteger (" " + time) ) ; // ... für die n ä c h s t e M e t h o d e dieses s p e i e h e r n

// Hl bi = bi .add ( (Biginteger) tl_temp. Stack .pop ()); tl_temp . Stack .push (bi) ; tl_temp .methodenStack .pop ( ) ; return rw;

public synchronized Biginteger getTime (String thread) { int index;

ThreadVerlaengern tl temp; index = getlndex (thread) ; if (index >= 0) { tl_temp = (ThreadVerlaengern) 11.get (index) ; // Zeit zurückgeben return tl_temp. time; ; eise { tl_temp = new ThreadVerlaengern (0, thread) ; 11. add (tl_temp) ; return (new Biginteger (" 0 ")); } ;

public synchronized void setTime (String thread, String time) { int index; ThreadVerlaengern tl temp; index = getlndex (thread) ; if (index >= 0) { tl_temp = (ThreadVerlaengern) 11.get (index) ;

// Zeit zurückgeben tl_temp. time = new Biginteger (time) ; } eise { tl_temp = new ThreadVerlaengern (0 , thread) ; ll.add(tl_temp) ; tl_temp. time = new Biginteger (time) ; }

public synchronized int getlndex (String thread) { ThreadVerlaengern tl_temp;

if (ll.sizeO == 0) { return -1;

}

Listlterator Ii = 11. listlterator (0) ; tl_temp = (ThreadVerlaengern) 11. get (0);

if (tl_temp . thread. equals (thread) ) return Ii .previouslndex () + 1; eise while (li.hasNext () ) { tl_temp = (ThreadVerlaengern) li.next();

if (tl_temp . thread. equals (thread) ) return Ii .previouslndex ();

} return -1;

}

public synchronized void exit (ThreadVerlaengern tl) {

ThreadVerlaengern tl_temp;

if (ll.contains (tl) ) { tl temp = (ThreadVerlaengern) 11 . get ( (11 . indexOf (tl ) ) ) ; tl_ temp . l ogtiefe-- ; } eise ll . add (tl ) ;

}

Für jeden Thread wird ein Objekt in die verkettete Liste auf- genommen, um bereits verlängerte Zeiten aus den Unteraufrufen weiterzugeben. Diese Zeiten werden in jedem Advice angepasst. Das Listing ist wie folgt:

package verlaengern; Import java .math .Biginteger; Import java. ut11.Stack;

public class ThreadVerlaengern { public long logtiefe = 0;

public String thread = " ";

public Biginteger time;

public Stack Stack;

public Stack methodenStack;

public ThreadVerlaengern (long logtiefe, String thread) { this . logtiefe = logtiefe; this .thread = thread; this . time = new Biginteger (" -1 "); this . Stack = new Stack (); this .methodenStack = new Stack (); ;

Claims

Patentansprüche

1. Verfahren zum rechnergestützten Bestimmen des Optimierungspotentials eines Softwaresystems, das eine Vielzahl an Modulen (A, B, C) umfasst, die beim Ablauf des Softwaresys^¬ tems zumindest teilweise miteinander interagieren können, bei dem a) von der Vielzahl an Modulen (A, B, C) zumindest ein zu untersuchendes Modul (B) bestimmt wird, welches hin- sichtlich der Auswirkung einer Optimierung des zumindest einen zu untersuchenden Moduls auf den Gesamtressourcenverbrauch des Softwaresystems untersucht werden soll; b) ein jeweiliger Ressourcenverbrauch eines oder mehrerer oder aller nicht zu untersuchender Module (A, C) der Vielzahl an Modulen (A, B, C) gemäß zumindest einem vorgegebenen Kriterium variiert wird, wodurch ein modifiziertes Softwaresystem erhalten wird; c) der Gesamtressourcenverbrauch des modifizierten Softwaresystems unter Berücksichtigung der Variation der nicht zu untersuchenden Module (A, C) ermittelt wird; und d) der ermittelte Gesamtressourcenverbrauch des modifizierten Softwaresystems mit dem Gesamtressourcenverbrauch des unmodifizierten Softwaresystems verglichen wird.

2. Verfahren nach Anspruch 1, bei dem die Variation des Ressourcenverbrauchs eine Vergrößerung des Ressourcenverbrauchs ist .

3. Verfahren nach Anspruch 1 oder 2, bei dem im Falle eines deterministischen Softwaresystems das vorgegebene Kriterium ein Faktor ist, um den der Ressourcenverbrauch der nicht zu untersuchenden Module (A, C) variiert wird.

4. Verfahren nach Anspruch 3, bei dem für sämtliche der nicht zu untersuchenden Module (A, C) ein gleicher Faktor gewählt wird.

5. Verfahren nach Anspruch 3, bei dem für die nicht zu untersuchenden Module (A, C) unterschiedliche Faktoren gewählt werden .

6. Verfahren nach Anspruch 1 oder 2, bei dem im Falle eines nicht deterministischen Softwaresystems das vorgegebene Kriterium ein jeweiliger Faktor für jedes der nicht zu untersuchenden Module (A, C) ist, der sich aus der Multiplikation eines oder eines jeweiligen Optimierungsfaktors mit einer jeweils für das betreffende Modul ermittelten Ressourcenverbrauch, insbesondere der Laufzeit, ergibt.

7. Verfahren nach Anspruch 6, bei dem der für ein betreffen- des Modul ermittelte, variierte Ressourcenverbrauch, insbesondere die Laufzeit, an aufrufende Module des Softwaresystems übertragen und bei der Ermittlung des variierten Ressourcenverbrauchs eines aufrufenden Moduls berücksichtigt wird.

8. Verfahren nach einem der vorherigen Ansprüche, bei dem bei der Ermittlung des Gesamtressourcenverbrauchs des modifizierten Softwaresystems die Messergebnisse der nicht zu berücksichtigenden Module normiert werden.

9. Verfahren nach einem der vorherigen Ansprüche, bei dem die Schritte gemäß einem der vorhergehenden Ansprüche mit unterschiedlichen Variationen der nicht zu untersuchenden Module (A, C) wiederholt ausgeführt werden.

10. Computerprogrammprodukt, das direkt in den internen Speicher eines digitalen Computers geladen werden kann und Softwarecodeabschnitte umfasst, mit denen die Schritte gemäß einem der vorherigen Ansprüche ausgeführt werden, wenn das Pro- dukt auf einem Computer läuft.