Geschwindigkeit static

[Evolver]

Eines vorweg: Ich weiß, meine Art der "Performancemessung" ist ungenau und wird einigen hier nciht gefallen. Aber davon abgesehen:


Ich habe folgende Testklasse geschrieben:

public class Test
{
	public static Test instance = new Test();
	
	public static void blubberS()
	{
		// any algorithm
		int i=0;
		++i;
		--i;
	}
	
	public void blubber()
	{
		// any algorithm
		int i=0;
		++i;
		--i;
	}
	
	public static void main(String[] args) throws Exception
	{
		long startTime=System.currentTimeMillis();
        for (long i=0; i < 1000000000l; i++)
        {
        	Test.blubberS();
        }

        long diffTime=System.currentTimeMillis() - startTime;
        System.err.println( "Elapsed: " + diffTime + "ms." );

        
        startTime=System.currentTimeMillis();
        for (long i=0; i < 1000000000l; i++)
        {
        	Test.instance.blubber();
        }
        diffTime=System.currentTimeMillis() - startTime;
        System.err.println( "Elapsed: " + diffTime + "ms." );
	}
}

Es zeigt sich, dass der nicht-statische Methoden-zugriff mithilfe einer statischen Klasseninstanz im Schnitt etwa 15% bis 20% schneller ist, als der direkte Aufruf der statischen Methode. Warum ist das so?

 

[Wildcard]

Eines vorweg: Ich weiß, meine Art der "Performancemessung" ist ungenau und wird einigen hier nciht gefallen. Aber davon abgesehen:

Es zeigt sich, dass der nicht-statische Methoden-zugriff mithilfe einer statischen Klasseninstanz im Schnitt etwa 15% bis 20% schneller ist, als der direkte Aufruf der statischen Methode.

Es zeigt sich, das du die Argumente warum solche Messungen Unsinn sind, zwar gelesen, aber entweder nicht verstanden, oder bewusst ignoriert hast.

   public static void main(String[] args) throws Exception
   {
      long startTime=System.currentTimeMillis();
      for (long i=0; i < 1000000000l; i++)
      {
         Test.instance.blubber();
      }


        long diffTime=System.currentTimeMillis() - startTime;
        System.err.println( "Elapsed: " + diffTime + "ms." );

       
        startTime=System.currentTimeMillis();
        for (long i=0; i < 1000000000l; i++)
        {
           Test.blubberS();
        }
        diffTime=System.currentTimeMillis() - startTime;
        System.err.println( "Elapsed: " + diffTime + "ms." );
   }

Und schon habe ich das exakte Gegenteil 'bewiesen'

 

[maki]

Ja, du hast Recht, diese Art von tests sind vollkommen sinnfrei

Vertausche die Schleifen, sehe und erstarre... sie laufen gleichlang.

Liegt vielleicht an der Hotspot VM.

Nachtrag: Schon wieder zu langsam...

 

[Evolver]

<--- *erstarre*

 

[André Uhres]

Bei mir ist der direkte Aufruf der statischen Methode immer schneller, unabhängig von der Reihenfolge.

 

[Evolver]

OK, nun habe ich mcih endlich mal damit beschäftigt und verstanden, warum ein solchen Micro-Benchmarking keine Aussagekräftigen Ergebnisse liefert. Aber wie macht man es denn richtig? Ich habe einige Tipps zur Umgehung der Hotspot-Optimierung gefunden, aber so richtig das Gelbe vom Ei scheint das trotzdem nicht zu sein.

 

[Marco13]

Microbenchmarks sind immer schwierig. Es gibt Fälle, wo man eine grobe Richtung erkennen kann. So ganz grob kann man vielleicht sagen, dass man grundsätzlich nicht sowas machen sollte wie

void teste()
{
    start();
    for (int i=0; i<100000000; i++)
    {
        methodeA();
    }
    stopUndGibZeitAus();

    start();
    for (int i=0; i<100000000; i++)
    {
        methodeB();
    }
    stopUndGibZeitAus();
}

sondern dem JIT-Compiler auch die Möglichkeit geben, an beidem rumzubasteln, also z.B. sowas wie

void testeA(int n)
{
    start();
    for (int i=0; i<100000000; i++)
    {
        methodeA();
    }
    stopUndGibZeitAus();
}

// testeB(int n) analog...

void teste()
{
    for (int n=100; n<10000000; n*=10)
    {
        testeA(n);
        testeB(n);
    }
}

Aber das ist eher eine Daumen- als eine Faustregel :wink: In gewisser Hinsicht ist deine "Kern-Methode" noch problematischer:

public void blubber()
   {
      // any algorithm
      int i=0;
      ++i;
      --i;
   }

Ein "schlauer" Compiler könnte das komplett wegoptimieren! Man muss z.B. bei den meisten C/C++-Compilern damit rechnen, dass eine Schleife wie

for (int i=0; i<1000000; i++) { }

tatsächlich eine Ausführungszeit von 0.0 hat - der Compiler merkt, dass dort nichts gemacht wird!

Verläßlicher (nicht verläßlich, aber verläßlicher) ist, wenn man ihn "zwingt", etwas zu machen.

int n = 0;
for (int i=0; i<1000000; i++) 
{ 
    n++;
}
System.out.println(n);

(theoretisch könnte sowas zwar auch zu einem
System.out.println(1000000);
optimiert werden, aber solche Optimierungen stoßen dann schnell an ihre Grenzen)


Zusammenfassend: Das ist alles Bullshit :wink: Wirklich verläßlich kann man Benchmarks nur mit einem guten Profiler machen, z.B. Optimizeit von Borland, oder ... vielleicht auch irgendwelchen freien, für Eclipse, oder dem, dem der bei NetBeans 6.1 dabei ist (abgesehen vom ersten habe ich die noch nicht verwendet, aber es gibt auch einige freie Java-Profiler, die IMHO ziemlich schlecht sind...)