ist es besser ein lokales Objekt zu erstellen.

[Chris_1980]

Hy,

hab da mal ne allgemeine frage, wenn ich eine Liste oder n Array durchgehe, und zwei oder mehr mal ne Methode aufrufe, wie in dem oberen Codefragment die getMethode der ArrayList, ist es dann Performance-technisch besser
ein lokales Objekt zu erstellen (wie im unteren Codefragment) und das dann zu benutzen oder bleibt das gleich? ???:L

			for(int i=0 ; i<blockList.size() ; i++)
			{
				
				if(blockList.get(i).getLifes() <= 0 
						&& !blockList.get(i).isPaintingHitAnimation())  blockList.remove(i);
			}

			Block b;
			for(int i=0 ; i<blockList.size() ; i++)
			{
				b = blockList.get(i);
				if(b.getLifes() <= 0 
						&& !b.isPaintingHitAnimation())  blockList.remove(i);
			}

 

[Beni]

Stell dir mal vor, "get" würde eine Sekunde zur Ausführung benötigen. Im oberen Fall wären das dann "blockList.size()*3" Sekunden, im unteren Fall nur "blockList.size()" Sekunden :arrow: mit einer lokalen Referenz kann man durchaus ein bisschen was gewinnen. Im Falle einer ArrayList ist das nicht sehr viel, bei einer LinkedList könnte es bereits bemerkbar sein.

P.S. und das "blockList.size()" könnte man auch durch eine Variable ersetzen, das Ding wird viel zu oft ausgeführt :wink:

 

[Lim_Dul]

Wobei size() meines Wissens bei den meisten (allen?) Listen in O(1) geht, daher ist das nicht so dramatisch.

 

[Chris_1980]

ok, danke für die Info.
(War mir einfach nicht sicher ob das nach dem Compilieren noch ne Bedeutung hat.)

MFG

 

[Marco13]

Man kann davon ausgehen, dass der Compiler das wegoptimiert (Im Zweifelsfall mal ein Testprogramm mit "ein paar Millionen" Schleifendurchläufen machen, und die Ausführungszeit messen, oder es im Profiler laufen lassen.).

Ich würde die dritte Variante verwenden

         for(int i=0 ; i<blockList.size() ; i++)
         {
            Block b = blockList.get(i);
            if(b.getLifes() <= 0
                  && !b.isPaintingHitAnimation())  blockList.remove(i);
         }

(d.h. die Deklaration IN der Schliefe), oder, wenn es sein muss, die zweite Variante von dir. Ganz allein schon deswegen, weil es viel übersichtlicher ist. Spätestens wenn man dann solche Konstrukte hat wie

     for(int i=0 ; i<blockList.size() ; i++) {
       for(int j=0 ; i<blockList.get(i).entries(); j++) {
         for(int k=0 ; i<blockList.get(i).getEntry(j).numElements() ; k++) {
         {
            blockList.get(i).getEntry(j).doSomethingWith(k).makeIt();
            blockList.get(i).getEntry(j).doSomethingWith(k).giveItToMe();
            blockList.get(i).getEntry(j).doSomethingWith(k).yeahReallyDoIt();
         }
       }
     }

sollte man das jeweilige element "zwischenspeichern"

 

[Marco13]

Und jetzt wo ich den Code nochmal lese: Wenn du aus der BlockList ein Element entfernst, solltest du danach
i--;
machen, sonst werden Elemente übersprungen!

 

[Leroy42]

Man kann davon ausgehen, dass der Compiler das wegoptimiert

Mit Sicherheit nicht! Woher soll denn der Compiler wissen,
was in der get-Methode so alles abgeht (Vielleicht schnell mal
ein paar Tausend Eintragungen in eine Datenbank? :shock: )

Wenn du mit Compiler allerdings den Just-In-Time Compiler meinst,
will ich mich mal nicht soweit aus dem Fenster lehnen; ich hab' keine
Ahnung, ob die auch methodenübergreifend optimieren. ???:L

 

[Marco13]

Ich bin davon ausgegangen, dass sich das "get" auf eine ArrayList o.ä bezieht. Und solche "Mini-Methoden" zu "inlinen" schafft vielleicht schon der "normale" Compiler, und der JIT-Compiler mit ziemlicher Sicherheit. Natürlich kann der Aufruf nicht "in jedem Fall" wegoptimiert werden. Es ist ja nichtmal gesagt, dass "get(i)" immer das gleiche Element liefern muss :wink:

 

[Leroy42]

Und solche "Mini-Methoden" zu "inlinen" schafft vielleicht schon der "normale" Compiler

Und nochmal: Nein! Der normale Compiler kann es nicht schaffen dürfen,
da er sich weder den Quelltext der get-Methode anschaut (Den gibt's oft gar nicht) noch
den bereits compilierten Byte-Code der Methode anschauen darf.
Für ihn ist einzig und allein die Methoden-Signatur (die er der .class-Datei entnimmt)
ausschlaggebend.

Stell' dir vor, du hast mit Java 1.5 ein Programm compiliert, das die
get-Methode benutzt. Nun wird mit Java 1.6 eine vollkommen andere
Implementation der ArrayList ausgeliefert und natürlich auch die
get-Methode entsprechend angepaßt. Das mit Java 1.5 compilierte Programm
würde dann unter Java 1.6 nicht mehr laufen können, wenn der Compiler
die get-Methode ge-inlined hätte. :shock:

Aus diesem Grund darf der Compiler (auch wenn er könnte) nichts inlinen. :noe:

Ich persönlich glaube sogar, daß auch der JIT nichts inlinen darf/kann,
bin mir deshalb aber absolut nicht sicher.

Gibt's hier irgendwo einen JIT-Experten, der uns da aufklären könnte? ???:L
Das jetzt zu :### habe ich leider keine Zeit.

 

[Marco13]

Nun - wenn ich schreibe "vielleicht", dann heißt das ungefähr das gleiche wie wenn ich schreibe "vielleicht nicht" :wink:

Jedenfalls habe ich gerade mal einen Testlauf gemacht...

import java.util.ArrayList;

class ArrayTest
{
    private static final int n = 500;
    private ArrayList<ArrayList<Integer>> array = new ArrayList<ArrayList<Integer>>();

    public static void main(String args[])
    {
    	new ArrayTest();
    }

    public ArrayTest()
    {
        init();
        for (int i=10; i<= 50; i+=10)
        {
    		testA(i);
    		testB(i);
    		testC(i);
		}
    }

    private void init()
    {
        for (int i=0; i<n; i++)
        {
            ArrayList<Integer> al = new ArrayList<Integer>();
            array.add(al);
            for (int j=0; j<n; j++)
            {
                al.add(new Integer(i*j));
            }
        }
    }


    private void testA(int runs)
    {
        long startTime = System.nanoTime();
        long result = 0;

		for (int k=0; k<runs; k++)
		{
			for (int i=0; i<array.size(); i++)
			{
				for (int j=0; j<array.get(i).size(); j++)
				{
					result += array.get(i).get(j).intValue() +
							  array.get(i).get(j).intValue() *
							  array.get(i).get(j).intValue();
				}
			}
		}

        long estimatedTime = System.nanoTime() - startTime;
        System.out.println("not stored "+result+ " average time "+(float)estimatedTime/runs/1000000+" ms");
    }


    private void testB(int runs)
    {
        long startTime = System.nanoTime();
        long result = 0;

		for (int k=0; k<runs; k++)
		{
			int size0 = array.size();
			for (int i=0; i<size0; i++)
			{
				ArrayList<Integer> a = array.get(i);
				int size1 = a.size();
				for (int j=0; j<size1; j++)
				{
					Integer v = a.get(j);
					result += v.intValue() + v.intValue() * v.intValue();
				}
			}
		}

        long estimatedTime = System.nanoTime() - startTime;
        System.out.println("stored     "+result+ " average time "+(float)estimatedTime/runs/1000000+" ms");
    }

    private void testC(int runs)
    {
        long startTime = System.nanoTime();
        long result = 0;

		for (int k=0; k<runs; k++)
		{
			for (int i=0; i<array.size(); i++)
			{
				ArrayList<Integer> a = array.get(i);
				for (int j=0; j<a.size(); j++)
				{
					Integer v = a.get(j);
					result += v.intValue() + v.intValue() * v.intValue();
				}
			}
		}

        long estimatedTime = System.nanoTime() - startTime;
        System.out.println("usual      "+result+ " average time "+(float)estimatedTime/runs/1000000+" ms");
    }

}

... und die Ergebnisse sind ziemlich eindeutig (JRE 1.6.0 b105)

Ohne JIT

not stored 405162376934800 average time 271.64194 ms
stored     405162376934800 average time 70.630066 ms
usual      405162376934800 average time 74.91389 ms
not stored 810324753869600 average time 273.24643 ms
stored     810324753869600 average time 81.826355 ms
usual      810324753869600 average time 74.64223 ms
not stored 1215487130804400 average time 274.09073 ms
stored     1215487130804400 average time 80.40213 ms
usual      1215487130804400 average time 74.216965 ms
not stored 1620649507739200 average time 273.9181 ms
stored     1620649507739200 average time 79.162605 ms
usual      1620649507739200 average time 76.7268 ms
not stored 2025811884674000 average time 274.98007 ms
stored     2025811884674000 average time 80.31631 ms
usual      2025811884674000 average time 75.060104 ms


Mit JIT

not stored 405162376934800 average time 14.466778 ms
stored     405162376934800 average time 4.2331305 ms
usual      405162376934800 average time 3.9609888 ms
not stored 810324753869600 average time 13.623138 ms
stored     810324753869600 average time 3.7420452 ms
usual      810324753869600 average time 3.4562316 ms
not stored 1215487130804400 average time 13.280036 ms
stored     1215487130804400 average time 3.2777224 ms
usual      1215487130804400 average time 3.3728511 ms
not stored 1620649507739200 average time 13.324659 ms
stored     1620649507739200 average time 3.2792883 ms
usual      1620649507739200 average time 3.3646226 ms
not stored 2025811884674000 average time 13.27716 ms
stored     2025811884674000 average time 3.274062 ms
usual      2025811884674000 average time 3.3679144 ms

Wenn man die Array-Elemente zwischenspeichert wird es (egal ob mit oder ohne JIT) schon DEUTLICH schneller (Das teuerste bei den ArrayList-Zugiffen ist aber mit Sicherheit die Bounds-Abfrage, und die spart man sich dann halt ziemlich oft). Das Zwischenspeichern der Arraygröße bringt aber fast nichts.

Zumindest bekräftigen die Zahlen teilweise das, was Leroy42 gesagt hat: Er kann es scheinbar nicht komplett wegoptimieren. (Und die Argumente waren auch VOR diesem Test schon überzeugend). Aber WAS genau der JIT dann noch macht, damit das ganze nochmal um den Faktor 20 (!!!) schneller wird, möge der potentielle JIT-Experte beantworten...

 

[Leroy42]

Jedenfalls habe ich gerade mal einen Testlauf gemacht...

Fleißig, fleißig! :applaus:

 

[Chris_1980]

jep, sehr windeutig, klasse. :toll: Aber wtf ist JIT ?

 

[Leroy42]

JIT

 

[Chris_1980]

OK, davon hab ich schonmal gehört, aber wenn der ein Teil der VM ist, wie kann man das dann ein oder ausschalten? :bahnhof:

 

[Marco13]

Standardmäßig ist er AN. Wenn man aber mit
java -Xint MeinProg
startet, wird er ausgeschaltet. (*gähn* :wink: )