Frage zur Deklaration von Variablen und deren Ressourcen

[Kaffeebohne]

Was verbraucht mehr Ressourcen:

int i = 0;
while(i <= 1000) {
	int foo = i + 5;
	i++;
}

oder

int foo = 0;
int i = 0;
while(i  <= 1000) {
	foo = i + 5;
	i++;
}

Und ne andere Frage aber passend. Wäre das obere Beispiel nicht bessere Programmierstil, da man sofort sieht das foo nur zu whileschleife gehört?

 

[Sky]

Benutze die Suchfunktion!!!

 

[Kaffeebohne]

Hab ich doch nach "deklaration" + "schleifen deklaration". ???:L

 

[Illuvatar]

Ich denk das obere braucht mehr Resourcen da da ja tausende ints angelegt werden.

 

[thE_29]

Verschoben!

Performance!

 

[dotlens]

http://www.java-forum.org/de/viewtopic.php?t=14882&start=0
wenn dann musst du foo final machen.

 

[Sky]

Was ist eigentlich Hintergrund deiner Frage??

 

[Thomas Darimont]

Hallo!

Um solche "Kleinigkeiten" herauszufinden schaut man sich in der Regel den Produzierten
Bytecode an.

/*
 * Created on 04.05.2005@17:03:49 by Darimont
 *
 * TODO Licence info
 */
package de.tutorials;

/**
 * @author Darimont
 * 
 * TODO Explain me
 */
public class FooTest {

	public static void main(String[] args) {
		long time = -System.currentTimeMillis();
		methodA();
		System.out.println(time + System.currentTimeMillis());

		time = -System.currentTimeMillis();
		methodB();
		System.out.println(time + System.currentTimeMillis());
	}

	/**
	 *  
	 */
	private static void methodB() {
		int i = 0;
		while (i <= 1000000000) {
			int foo = i + 5;
			i++;
		}
	}

	/**
	 *  
	 */
	private static void methodA() {
		int foo = 0;
		int i = 0;
		while (i <= 1000000000) {
			foo = i + 5;
			i++;
		}
	}
}

javap de.tutorials.FooTest -c -private
ergibt:

...

private static void methodB();
  Code:
   0:   iconst_0 // Lege int mit Wert 0 auf den Stack
   1:   istore_0 // Nimmt den int vom Stack und speichert ihn in der lokalen Variablen(0)
   2:   goto    12 //gehe zur Marke 12
   5:   iload_0 // lege lokale Variable(0) auf den Stack
   6:   iconst_5 // Lege int mit Wert 5 auf den Stack 
   7:   iadd // Nehme zwei int Werte vom Stack, addiere diese und lege das Ergebnis zurück
   8:   istore_1 // Nimmt den int vom Stack und speichert ihn in der lokalen Variablen(1)
   9:   iinc    0, 1 // Inkrementiere die lokale variable(0) um 1
   12:  iload_0 // lege lokale Variable(0) auf den Stack
   13:  ldc     #42; //int 1000000000  // lege int mit Wert 1000000000   auf den Stack
   15:  if_icmple       5 // Nimmt die beiden obersten Werte vom Stack und vergleicht diese. Wenn der Wert(0)<=Wert(1) dann springe zur Marke 5
   18:  return // return. Blockabschluss

private static void methodA();
  Code:
   0:   iconst_0 // Lege int mit Wert 0 auf den Stack

   1:   istore_0 // Nimmt den int vom Stack und speichert ihn in der lokalen Variablen(0)
   2:   iconst_0 // Lege int mit Wert 0 auf den Stack
   3:   istore_1 // Nimmt den int vom Stack und speichert ihn in der lokalen Variablen(1)
   4:   goto    14 //Gehe zur Marke 14
   7:   iload_1 // lege lokale Variable(1) auf den Stack
   8:   iconst_5 // Lege int mit Wert 5 auf den Stack
   9:   iadd // Nehme zwei int Werte vom Stack, addiere diese und lege das Ergebnis zurück auf den Stack.
   10:  istore_0 // Nimmt den int vom Stack und speichert ihn in der lokalen Variablen(0)
   11:  iinc    1, 1 // Inkrementiere die Lokale Variable(1) um 1
   14:  iload_1 // lege lokale Variable(1) auf den Stack
   15:  ldc     #42; //int 1000000000 // lege int mit (int) Wert 1000000000   auf den Stack
   17:  if_icmple       7 //Nimmt die beiden obersten Werte vom Stack und vergleicht diese. Wenn der Wert(0)<=Wert(1) dann springe zur Marke 7
   20:  return // return. Blockabschluss

Könnte vielleicht jemand sagen wieviele "Ticks" die jeweilige operation verschlingt?
Ich würde sagen, dass der Aufwand die schnellere Variante zu ermitteln in keinem Verhältnis zu dem Ergbenis steht...
ganz besonders unter dem Gesichtspunkt, dass das oben geziegte unter der server-VM in
0 ms durchläuft ;-)
(Versuchts doch mal selbst: java -server de.tutorials.FooTest )

Gruß Tom

 

[Bleiglanz]

das ist auch quatsch, weil der Bytecode von Java nicht besonders gut optimiert ist

zur Laufzeit geht da nochmal der JIT Compiler drüber, der weitere Optimierungen vornimmt...

 

[Scotty]

import java.util.*;

class PerformanceTest
{
	int durchlauf;
	
	public PerformanceTest(int durchlauf)
	{
		this.durchlauf=durchlauf;
	}
	
	long ZuweisungA()
	{
		long t1=new Date().getTime();
		int x=0;
		for(int i=0;i<this.durchlauf;i++)
		{
			x=i+1;
		}
		long t2=new Date().getTime();
		return t2-t1;
	}
	
	long ZuweisungB()
	{
		long t1=new Date().getTime();
		for(int i=0;i<this.durchlauf;i++)
		{
			int x=i+1;
		}
		long t2=new Date().getTime();
		return t2-t1;
	}
}

class MainTest
{
	public static void main(String args[])
	{
		PerformanceTest p=new PerformanceTest(10000000);
		long l1=p.ZuweisungA();
		long l2=p.ZuweisungB();
		System.out.println("A:"+l1+"\n"+"B:"+l2);
	}
}

Testet man beide Zuweisungen nacheinander, kommen immer ziemlich unterschiedliche Werte heraus. Woran das liegt, keinen Plan. Startet man das Programm aber erst mit A und dann mit B, unterscheiden sich die Zuweisungen bei der gegenwärtigen Anzahl der Durchläufe nur um die Differenz B-A=1, also fast nix.

 

[Thomas Darimont]

Hallo!

das ist auch quatsch, weil der Bytecode von Java nicht besonders gut optimiert ist

Vielleicht der des Sun Compilers

zur Laufzeit geht da nochmal der JIT Compiler drüber, der weitere Optimierungen vornimmt...

Bis der JIT aktiv wird dauert es aber seine Zeit...(das ist je nach VM (Server/Classic) unterschiedlich.
Aber bei solchen Codefragmenten wie oben geht die Server VM ein wenig anders vor als die Classic_VM. Die Server VM analysiert nämlich den Code und erkennt, dass die Schleife in der Methode nur von Methodenlokalen Variablen abhängt und eigentlich überhaupt keine 'äußeren' Variablen beeinflusst werden. Deshalb überspringt der der HotSpot diesen Teil und returniert deshalb sofort. Die Client-VM hingegen führt diese checks nicht durch und rattert durch die Schleife...


Gruß Tom

 

[Illuvatar]

Eine Nebenfrage mal: Was ist die Server VM eigentlich? Was macht die anders, wofür ist die gut?

 

[AskHL]

Illuvatar, es gibt zwei Hostspot JVM Ausgaben von Sun: Client und Server. Die Client VM wird ein programm schnell laden, wenn die Server VM einige optimierungen zuerst ausführt. Server VM ist also schneller, aber am Anfang noch langsamer als Client.

Du kannst viel Info über die JVM Ausgaben mit Google finden.

(I hope the grammar isn't too bad above - this isn't my native language)

 

[byte]

hm, ich finde diese frage auch interessant, aber irgendwie gehen die meinungen ja nun doch auseinander. vielleicht sind die gestellten beispiele in diesem und in dem anderen thread nicht so wirklich sinnvoll, weil jeweils primitive datentypen benutzt wurden. aber betrachten wir doch mal ein anderes beispiel, wo die objekte doch etwas größer sind, z.b. bilder von mehreren 100 kb:

1:

while (irgendwas) {
   BufferedImage img = new BufferedImage(...);
   ...
}

2:

BufferedImage img = null;
while (irgendwas) {
   img = new BufferedImage(...);
   ...
}

ist es nun sinnvoller 1 oder 2 zu verwenden? wenn ich die postings bisher richtig gedeutet habe, sollte 1 besser sein wegen der unnötigen scope ausweitung ausserhalb der schleife bei 2.

und was ist nun, wenn nur im weiteren programmverlauf nur lesend auf img zugegriffen wird. ist es dann nötig, auf final zu setzen, um ne bessere performance zu erzwingen? oder kann man sich das final auch sparen? bin bisher nie auch nur auf die idee gekommen, final für solche zwecke einzusetzen. hab wohl irgendwie angenommen, die jvm is schlau genug read only von selbst zu erkennen. :roll:

 

[AlArenal]

1. final geht an der Stelle gar nicht (nur im Scope der ganzen Klasse)
2. Schonmal versucht nem final nen anderen Wert zuzuweisen?
3. Die JVM kann wohl kaum erkennen ob du nur lesend irgendworauf zugreifst, denn es gibt noch so nette Sachen wie Reflection...

 

[byte]

1. final geht an der Stelle gar nicht (nur im Scope der ganzen Klasse)
2. Schonmal versucht nem final nen anderen Wert zuzuweisen?
3. Die JVM kann wohl kaum erkennen ob du nur lesend irgendworauf zugreifst, denn es gibt noch so nette Sachen wie Reflection...

zu 1. warum hat das dann niemand in http://www.java-forum.org/de/viewtopic.php?t=14882&start=0 geschrieben? dort steht final int im scope der for-schleife. das wäre dann ja unmöglich und der ganze thread demnach unsinnig.
zu 2. mir ist der sinn von final schon klar, allerdings habe ich final in der praxis bisher nahezu gar nicht eingesetzt. es geht mir darum, ob es einen unterschied in sachen performance gibt zwischen folgenden code-fragmenten (was aber nach 1. dann ja unmöglich wäre):

while(irgendwas) {
   final BufferedImage img = ...;
   ...
}

while(irgendwas) {
   BufferedImage img = ...;
   ... // hier NUR lesender zugriff auf img
}

zu 3. reflection sagt mir nichts, aber das ist dann wohl ein anderes thema und gehört hier nicht her.


ps: um meine erste frage (ob (1) oder (2) performanter ist) hast du dich geschickt rummanövrier...

 

[AlArenal]

Oopsi, Fehler meinerseits (noch nicht ganz nüchtern)

Ich verwende final eigentlich nur für Klassen-Konstanten und für Methoden-Parameter. Ne Variable in einem lokalen Verwendungsbereich final zu deklarieren, kann aber keinen Speed-Vorteil bringen, weil sie ja zunächst dennoch mit einem variablen Wert (der danach nicht mehr verändert werden kann) initialisiert wird. Es ist dann lediglich eine nicht mehr änderbare Variable, aber keine im Bytecode hartverdrahtete Konstante. Das sollte dann die Frage 2 beantworten.

Der Compiler geht davon aus, dass du weißt was du tust. Wenn ich ne Klasse erweitere, in der ich eine deiner Variablen ändere, die du nicrgends änderst, könnte ich auf deine übersrtzte Lib ja nicht zugreifen.

In deinem Beispiel sagt final nur, das die Variable nach der Initialisierung nicht mehr geändert werden darf. Mehr nicht. Da rechts vom Gleichheitszeichen aber ne Variable stehen kann, kann da nichts hartverdrahtet oder optimiert werden. Es dient dann lediglich als Sicherungsmechanismus, um nicht versehentlich doch was zu ändern und dann lange debuggen müssen (daher auch die Taktik mit dem final für Methodenparameter).

 

[AlArenal]

P.S.:

Wenn du es mal in deinen Anwendungen selbst austestest und du keinen Unterschied feststellst, ist dieser Unterschied - soweit überhaupt vorhanden - so vernachlässigbar klein, dass du die Zeit statt zum Diksutieren besser zum Coden genutzt hätest.

If it ain't broke - don't fix it!