Array

[Network]

Hi,

ich hätte da mal eine Frage über das Array:
Läuft die Addressierung gleich ab wie bei normalen Variablen?

Genauer: Mein alter Informatiklehrer sagte mir in den Anfangsjahren bei einem Blick in meinen Quellcode, dass ich nicht ständig auf das Array in der For-Schleife zugreifen soll, wegen Geschwindigkeitseinbußen.
Das sah in etwa so aus:

for( int i = 0; i < a.length; i++ ) {
     a[i].sayHello();
     a[i].doSomething();
     a[i].voteQuimby();
}

Die Aussage kam mir jetzt wieder in den Kopf und die Frage ist, ob es stimmt.
Sollte man es wirklich lieber so machen:

for( int i = 0; i < a.length; i++ ) {
     Klasse ia = a[i];
     ia.sayHello();
     ia.doSomething();
     ia.voteQuimby();
}

Btw. ich weiss man kann die for-Schleife kürzer schreiben, aber das ist im Moment irrelevant.

Danke
Gruß
Net

 

[XHelp]

Rein theoretisch betrachtet hat er nicht ganz unrecht, denn jedes mal, wenn du auf ein Array zugreifst, wird zunächst geprüft, ob der Index auch innerhalb der Länge des Arrays liegt (JLS 15.13.1), aber solche Überlegungen lassen sich heutzutage in Java oft vernachlässigen. Im Hintergrund werden so viele Sachen wegoptimiert, dass es durch aus sein kann, dass es auf der praktischen Ebene völlig egal ist.
Wenn man es ziemlich streng mit der Optimierung nimmt, müsste man die for-Schleife generell umschreiben:

int length = a.length; //damit nicht jedes mal abgefragt wird
for( int i = 0; i < length; i++ ) {
//oder überhaupt
for( int i = a.length; --i>=0;) {

Die letzte Variante ist semantisch nicht ganz die selbe, aber auf der theoretischer Ebene läuft die schneller ab, weil nativ der Vergleich mit 0 schneller abläuft. Praktisch gesehen ist das völlig irrelevant, weil die Schleifen von HotSpot optimiert werden.

 

[faetzminator]

Und genau genommen spielt das in diesem Fall auch keine Rolle, da du doch eher die for-each-Schleife verwenden würdest Aber ansonsten - wie immer: Mag interessant für ein Gespräch sein, jedoch in der Praxis absolut vernachlässigbar.

 

[Network]

Vielen Dank!

Und genau genommen spielt das in diesem Fall auch keine Rolle, da du doch eher die for-each-Schleife verwenden würdest

Btw. ich weiss man kann die for-Schleife kürzer schreiben, aber das ist im Moment irrelevant.

Hmm naja die For-Schleife war im Grunde nur ein Beispiel. Es muss ja nicht unbedingt eine Schleife sein. Das war jetzt der ungefähre Kontext zur Aussage...

Ein anderes Beispiel wäre, dass man ein Feld aus 42x42 (42 = keine Ahnung wieviele) Rechtecken hat, die untereinander jedoch nur auf Nachbarrechtecke zugreifen können - direkt angrenzend.

Man könnte die Nachbarrechtecke in einem ExtraArray oder einer ExtraListe speichern mit 4 Einträgen. Man könnte aber auch 4 Variablen verwenden.
Oder man entnimmt dem großen alles enthaltenem Array per IndexX +- 1 und IndexY +- 1 die Einträge.

Vieleicht ändert sich hier nochmal der Sachverhalt oder es ist weiterhin

irrelevant

.

 

[XHelp]

Dein neues Beispiel hat verschiedene semantische Bedeutungen. Im "ExtraArray"-Fall muss eine Zelle seine Nachbaren selber kennen, in dem "ein Array"-Fall nicht.
Und so leicht lässt es sich nicht beantworten, denn so oder so musst du auf ein Array zugreifen und darüber hinaus musst du noch bei "ExtraArray"-Fall ja die Liste auch Synchron halten, so dass da der Aufwand größer ist.

Wie gesagt: Optimierung auf dieser Ebene ist nicht ganz einfach und vor allem nicht ganz sinnvoll. Du müsstest schon exakt wissen wie jede einzelne Aktion intern ausgewertet wird und vor allem was unter welchen Bedingungen zu was von dem Compiler/HotSpot optimiert wird.

 

[Nardian]

Hi,

meiner Erfahrung nach lohnt es sich ohnehin nicht sich über sowas ernsthaft Gedanken zu machen. die JVM ansich ist durchaus sehr mächtig, und solche beinahe "trivialen" Optimierungen sollten spätestens zur Laufzeit von der JVM selber gemacht werden.

Anderes Beispiel dafür wäre, ob man innerhalb einer Schleife eine neue Variable zum Arbeiten macht, oder außerhalb, und die Variable immer wieder überschreibt. Eigentlich würde letztes mehr Sinn machen, da nie ein neuer Speicherplatz gesucht werden muss, aber sowas müsste die JVM automatisch machen / optimieren können.

Lg

 

[Schandro]

Alle Rechner die jemals diese Codestelle ausführen werden brauchen zusammen kürzer als die Zeit in der du darüber nachgedacht und diesen Thread geschrieben hast

 

[Network]

Alle Rechner die jemals diese Codestelle ausführen werden brauchen zusammen kürzer als die Zeit in der du darüber nachgedacht und diesen Thread geschrieben hast

Das ist in der Regel mit jedem Stückchen Code so und hinzu noch der Grund warum wir heutzutage überhaupt so groß mit Rechenmaschinen arbeiteten. Mein Rechner braucht im Schnitt bei "Erstausführung" 21Nanosekunden um den Teil abzuhandeln. Ich müsste über den Teil nicht mehr als eine Sekunde nachgedacht haben und über 1000000000/20 leistungsgleiche Rechner müssten den Codeteil ausführen, damit deine Rechnung aufgeht.
Sorry aber Argument abgelehnt.

 

[Schandro]

Mein Rechner braucht im Schnitt bei "Erstausführung" 21Nanosekunden um den Teil abzuhandeln. Ich müsste über den Teil nicht mehr als eine Sekunde nachgedacht haben und über 1000000000/20 leistungsgleiche Rechner müssten den Codeteil ausführen, damit deine Rechnung aufgeht.
Sorry aber Argument abgelehnt.

Ich bin ein bisschen verwirrt, so wie ich das sehe ist das Ergebnis deiner Rechnung das mein Argument IN BEZUG AUF DEINEN Code richtig ist. Natürlich würde ich nicht dasselbe statement machen wenn jemand über Performanceoptimierungen vom Kernel o.Ä. nachdenken würde

Die Rechnung:
Gehirn braucht 1 Sekunde
durchschnittlicher PC braucht 21 nanosekunden

ergibt:
47.619.047 mal müsste die Codestelle ausgeführt werden, dann sind beide Zeiten gleich. Klingt für mich stark danach das meine These in dem Fall richtig ist, vorallem weil 1 Sekunde doch ein bisschen untertrieben ist

 

[Network]

Ich bin ein bisschen verwirrt, so wie ich das sehe ist das Ergebnis deiner Rechnung das mein Argument IN BEZUG AUF DEINEN Code richtig ist. Natürlich würde ich nicht dasselbe statement machen wenn jemand über Performanceoptimierungen vom Kernel o.Ä. nachdenken würde

Die Rechnung:
Gehirn braucht 1 Sekunde
durchschnittlicher PC braucht 21 nanosekunden

ergibt:
47.619.047 mal müsste die Codestelle ausgeführt werden, dann sind beide Zeiten gleich. Klingt für mich stark danach das meine These in dem Fall richtig ist, vorallem weil 1 Sekunde doch ein bisschen untertrieben ist

Ok führen wir das weiter
Ich habe ja auch nicht bewiesen dass deine These direkt falsch ist, sondern dass dein Argument keine Aussagekraft hat, da sie auf jeden Codeteil praktisch zutrifft und nicht nur auf diesen.
Wenn deine Argumentation ihre Wertigkeit hätte, hieße dass, das jeder Codebruchstück über den man länger nachdenkt als die Zeiten der Computer zusammengerechnet die ihn ausführen müssen es nicht Wert wäre was im Grunde jedem einzelnen entsprechen würde und man damit auch erst garnicht anfangen bräuchte darüber nachzudenken.

 

[Schandro]

Ok führen wir das weiter
Ich habe ja auch nicht bewiesen dass deine These direkt falsch ist, sondern dass dein Argument keine Aussagekraft hat, da sie auf jeden Codeteil praktisch zutrifft und nicht nur auf diesen.
Wenn deine Argumentation ihre Wertigkeit hätte, hieße dass, das jeder Codebruchstück über den man länger nachdenkt als die Zeiten der Computer zusammengerechnet die ihn ausführen müssen es nicht Wert wäre was im Grunde jedem einzelnen entsprechen würde und man damit auch erst garnicht anfangen bräuchte darüber nachzudenken.

Es gibt schon ein paar Codestellen bei denen es lohnenswert ist über Performanceverbesserungen nachzudenken. Wenn man beispielsweise sieht das da ein Stream byte-weise eingelesen wird anstatt einen buffer zu benutzen oder extrem viele Strings concatenated werden anstatt nen StringBuilder zu nehmen, oder wenn man hunderte einzelne SQL-Statements an die DB schickt anstatt ein passendes join o.Ä. zu benutzen, um mal die einfachsten zu nennen. An solchen Stellen kostet das nachdenken fast immer weniger Zeit als wenn viele PC's so etwas ausführen müssen.