Wikibooks

Das Performance-Handbuch: Softwareanalyse und Performance



Bevor wir uns den Vor- und Nachteilen widmen noch ein kleiner aber wichtiger Punkt. Performanceüberlegungen haben - bis auf wenige Ausnahmen - erst ab der Designphase eine Berechtigung. In der objektorientierten Analyse sind derartige Überlegungen meist unnötig. Die fachliche Analyse kann uns jedoch die Grundlagen schaffen, um im Design an der Performanceschraube zu drehen.

Nebenläufigkeit

Bearbeiten

Nebenläufigkeit oft auch Parallelität genannt ist ein wichtiger Punkt, welcher in der Analyse zu klären ist. Ich werde hier den m.E. genaueren Begriff Nebenläufigkeit verwenden. Nebenläufigkeit zu bestimmen bedeutet festzulegen, welche Aufgaben nebeneinander durchgeführt werden können. Während bei Einprozessorsystemen / Einkernsystemen meist nur eine subjektive Verbesserung der Geschwindigkeit zu verzeichnen ist[1], ist dies für Multiprozessorsysteme eine elementare Voraussetzung zur Ausnutzung der Besonderheiten des Betriebssystems.

Nur Sie als Fachexperte, welcher die Kenntnis hat, können festlegen, welche Abläufe tatsächlich nebenläufig stattfinden können. Mit der UML können Sie diese Nebenläufigkeiten mittels der Tätigkeitsdiagramme sehr gut darstellen. Dabei werden Anwendungsteile, welche nebenläufig sind, zwischen einem Synchronisationsbalken dargestellt. Beachten Sie jedoch, dass überflüssige Nebenläufigkeit, selbst falls diese möglich ist, in der Praxis nicht verwendet werden. Ein weiteres Problem ist das Schneiden von Nebenläufigkeiten. Sehr kleine Nebenläufigkeiten sind zwar sehr anwenderfreundlich, werden aber selten genutzt. Zu groß geschnittene Nebenläufigkeiten dagegen werden den Anwender verärgern. Ein gesundes Mittelmaß ist hier wichtig.

Beispiel: Während Sie das Finale der Fußballweltmeisterschaft im Fernsehen verfolgen, trinken Sie Ihr Bier. Oder während der Übertragung des Finales des Synchronschwimmens trinken Sie Ihr Glas Weißwein.

 

Asynchrone Methodenaufrufe

Bearbeiten

Asynchrone Methodenaufrufe sind ebenfalls ein wichtiges Ergebnis der Fachanalyse. Hier bestimmen Sie, ob auf ein Ergebnis einer Tätigkeit gewartet werden soll, bevor mit der nächsten Tätigkeit fortgefahren werden kann. Dies ist insbesondere im Netzwerkbereich eine gute Möglichkeit, die Performance zu erhöhen. Dort wird dieses Prinzip allgemein unter dem Begriff „Callback“ verwendet. Wir modifizieren unser Beispiel etwas ab. Nun soll der Ehemann auch Herr im Haus sein [2] und die Ehefrau anweisen, erstens zur Fußballübertragung umzuschalten und zweitens das Bier zu holen. Dies könnte nun ein Tätigkeitsmodell zu unserer Erweiterung sein. Aus diesem kann man jedoch leider nicht entnehmen, ob hier asynchrone Methodenaufrufe möglich sind.

 

In unserem Beispiel müsste der Ehemann zwar warten bis das Getränk geholt wurde, bevor er trinken kann, er könnte jedoch den Fernseher durchaus betrachten, bevor die Ehefrau umgeschaltet hat. Um dies darzustellen bieten sich die Interaktionsdiagramme an. Ein entsprechendes Diagramm könnte dann so aussehen:

 

Die Beschreibungssprache UML ist eine Möglichkeit in der OO Analyse[3].

Wertebereich

Bearbeiten

Die Festlegung des Wertebereichs ist eine wesentliche Aufgabe der OOA. Der Wertebereich gibt uns für das Design die benötigten Vorgaben, um den Typ einer Variablen festzulegen. Falls Sie sich schon mit Performance und Java beschäftigt haben, werden Sie eventuell zu der Ansicht kommen, der Typ int sei für Ganzzahlen zu bevorzugen, da er der schnellste Typ ist. Richtig! Sie sollten hier jedoch Analyse und Design besser trennen. Die Analyse legt den Wertebereich fest. Das Design bestimmt, welcher Typ den tatsächlichen Wert enthält. Ein Beispiel soll den Unterschied etwas verdeutlichen: Wir nehmen das Standardbeispiel – eine Person. In unserem Beispiel wollen wir lediglich das Alter einer Person speichern. In der Analysephase würden Sie eine Ressource Person entwickeln, welche Ihr Alter kennt. Das Alter soll eine Ganzzahl mit einem Wertebereich von 0 bis 200 [4] sein. Die Analyse legt somit fest, dass wir eine Ganzzahl benötigen, die 200 verschiedene Werte aufnehmen kann.

Im Design liegen jedoch andere Prämissen. Hier ist es sinnvoll für die Ausführungsgeschwindigkeit z.B. in Java den Typ zur Laufzeit als int festzulegen. Es kann jedoch sein, dass wir für das Sichern unserer Werte den Typ short bzw. byte verwenden wollen, da diese bereits entsprechende Werte aufnehmen können und weniger Speicherplatz benötigen.

Die Trennung von Analyse und Design ist hier für unsere Performanceüberlegungen nötig, da nur so beide Seiten, hier Speicherbedarf und Ausführungsgeschwindigkeit, betrachtet werden. Für die Ausführungsgeschwindigkeit wird dem schnellen primitiven Typ int der Vorzug gegeben. Für die Sicherung wird jedoch der Typ byte verwendet, welcher weniger Speicherplatz benötigt.

  1. ↑ Die tatsächliche Geschwindigkeit kann durch den Overhead der Threaderstellung bzw. den Wechsel zwischen den Threads sogar abnehmen.
  2. ↑ Ein eher seltener Fall.
  3. ↑ Eine genaue Beschreibung der Möglichkeiten der Unified Modeling Language [UML] und der Objektorientierung würde hier den Rahmen sprengen.
  4. ↑ Dies sollte selbst für langlebige Personen ausreichen.



Abgerufen von „https://de.wikibooks.org/w/index.php?title=Das_Performance-Handbuch:_Softwareanalyse_und_Performance&oldid=812049“