Performanceoptimierung der Datenanalyse in Netzwerkgraphen durch
Performanceoptimierung der Datenanalyse in Netzwerkgraphen durch
Performanceoptimierung der Datenanalyse in Netzwerkgraphen durch
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
4. Optimierungen <strong>in</strong> <strong>der</strong> Implementierung<br />
vor und nach dem Dijkstra-Algorithmus, jedoch nicht mehr während se<strong>in</strong>er<br />
Ausführung verwendet wird.<br />
Generell lässt sich hier auch gut erkennen, dass im Rahmen dieser Arbeit<br />
nicht auf Speicherplatz son<strong>der</strong>n nur auf Zeit optimiert wurde. Bei <strong>der</strong>artig kle<strong>in</strong>en<br />
Graphen (n ≈ 200) braucht auf die Art <strong>der</strong> Verwaltung im Arbeitsspeicher,<br />
bei heutigen Computern, nicht geachtet zu werden.<br />
Wie bereits im Abschnitt 4.1.1 erklärt wurde die Klasse FibonacciHeap aus<br />
dem JGraphT-Framework übernommen. Die Klasse wurde jedoch im Zuge dieser<br />
Optimierung nochmal komplett überarbeitet, da das Framework ebenfalls<br />
für allgeme<strong>in</strong>e Graphen optimiert ist. So konnte je<strong>der</strong> enthaltene Knoten e<strong>in</strong><br />
beliebiges Objekt se<strong>in</strong>, zu dem diverse Zusatz<strong>in</strong>formationen gespeichert wurden.<br />
Dies wurde alles auf den Datentyp <strong>in</strong>t reduziert und alle <strong>in</strong> dieser Klasse<br />
verwendeten vorgefertigten Java-Klassen entfernt. Die neue Klasse wurde<br />
FastFibonacciHeap genannt. Die <strong>durch</strong> diese Optimierung erreichte Zeitersparnis<br />
war sehr ger<strong>in</strong>g. Wie zu erwarten war, brachte diese Optimierung den<br />
kle<strong>in</strong>sten Teil <strong>der</strong> Zeitersparnisse e<strong>in</strong>.<br />
4.2.3. Design Pattern<br />
E<strong>in</strong>e Beson<strong>der</strong>heit bei <strong>der</strong> mo<strong>der</strong>nen Programmierung mit objektorientierten<br />
Programmiersprachen ist die Verwendung von Design Pattern (engl. für Entwurfsmuster).<br />
Softwaretechniker kennen e<strong>in</strong>e ganze Reihe von Design Pattern,<br />
welche die Wie<strong>der</strong>verwendbarkeit und Verän<strong>der</strong>barkeit von Quelltext stark erhöhen.<br />
Auf Design Pattern wurde im Rahmen dieser Arbeit weitestgehend<br />
verzichtet.<br />
Insbeson<strong>der</strong>e solche Pattern wie Factory o<strong>der</strong> Strategy wurden bewusst weggelassen,<br />
da sie zur Laufzeit e<strong>in</strong>e Zeichenkette auslesen, um danach dann e<strong>in</strong>e<br />
bestimmte Klasse zu laden o<strong>der</strong> e<strong>in</strong>en bestimmten Algorithmus auszuführen.<br />
Diese Pattern s<strong>in</strong>d vergleichsweise langsam. Normalerweise ist dieser Geschw<strong>in</strong>digkeitsunterschied<br />
nicht relevant, aber <strong>in</strong> <strong>der</strong> performanceoptimierten Programmierung<br />
sollte nach Möglichkeit darauf verzichtet werden. Factory hätte<br />
z. B. dafür benutzt werden können, die Klasse für den Fibonacci-Heap dynamisch<br />
auszutauschen und mit Strategy hätte man sich zur Laufzeit dynamisch<br />
für verschiedene Graphenalgorithmen entscheiden können.<br />
E<strong>in</strong> Nachteil <strong>der</strong> hier entstandenen Implementierung ist, dass die Metrik<br />
nicht problemlos austauschbar ist. Die Metrik zur Berechnung des Abstands<br />
zwischen zwei Knoten ist fest <strong>in</strong> den Algorithmus e<strong>in</strong>programmiert. E<strong>in</strong> austauschbarer<br />
Komparator o<strong>der</strong> e<strong>in</strong> Strategy-Pattern mit wechselbaren Metriken<br />
hätten hier Abhilfe geschafft wurden jedoch aus Performancegründen nicht e<strong>in</strong>-<br />
© Andreas Redmer — 29. September 2011 54
Change language