Nachdem ich in einem meiner vorherigen Artikel über Pläne zu meiner Weiterbildung schrieb, habe ich nochmals einen Gedanken wieder aufgegriffen, mit dem ich mir schon verschiedentlich die Zeit vertrieb...

Einleitung

Ich habe bereits in einem früheren Artikel über meine Ablehnung gegenüber syntactic sugar geschrieben. Ich muss hier gleich vorausschicken, dass das, was ich in diesem Artikel geschrieben habe durch meine Analysen falsifiziert wurde.

Den Quelltext der Klasse, mit der ich die Benchmarks durchführte, ist an unten in diesem Artikel angehängt. Die Bytecodes sieht man, indem man das Kommando

javap -c -private 

auf die kompilierte Klasse anwendet.

Cast gegen implizite Konvertierung

int a=1;
int b=3;
double result=a/b;

zu einem Wert von 0.0 für die Variable result führen, da die Rechte Seite zuerst ausgewertet und dann der Double-Variable zugewiesen wird. Wer als Resultat 0.3333333 sehen möchte, muss dafür sorgen, dass a und b bei der Auswertung der rechten Seite als Double-Zahlen angesehen werden. Das kann man auf vewrschiedenen Wegen erreichen: einmal kann man beide Zahlen vor der Auswertung mit 1.0 multiplizieren - das entstehende Zwischenergebnis ist dann eine Double-Zahl und damit ist der gesamte Ausdruck auf der rechten Seite ebenfalls eine:

double result=(a*1.0)/(b*1.0);

Die zweite Möglichkeit ist ein expliziter Cast:

double result=(double)a/(double)b;

In der Auswertung der Benchmarks unterschieden sich beide Lösungen nicht voneinander - mal war die eine marginal schneller, mal die andere. Ein klarer Fall von Syntactic sugar.

Drei verschiedene Arten über eine Liste zu iterieren

for(int i=0;i<l.size();++i)

statt

int size=l.size();
for(int i=0;i<size;++i)

schreibt. Wenig überraschend ergab sich ein leichter Vorteil für Lösung zwei: Die Funktion wird tatsächlich bei jedem Schleifendurchlauf ausgewertet, was für das etwas schlechtere Laufzeitverhalten sorgt. Nachdem ich damit fertig war, wollte ich wieder eine Bestätigung des "syntactic sugar"-Vorurteils haben und probierte:

for (String string : l)

Ich fiel fast vom Stuhl: Wo meine beiden ersten Versuche um die 6 Sekunden brauchten, brauchte diese Variante unter ansonsten identischen Voraussetzungen um die 10 Millisekunden!! Das ist ein Speedup von fast 1000!!! Jetzt ist es denke ich an der Zeit, meinen Code auf die Benutzung der Funktion size() zu untersuchen und überall da, wo anhand dieser Funktion iteriert wird, Änderungen einzuführen...

Lizenz

ByteCodeAnalysis

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )