Warum ist static final langsamer als eine neue auf jeder Iteration

Question

Warum Code ist ein 14x langsamer als Code-Schnipsel B-Snippet?
(getestet mit jdk1.8.0_60 auf Windows 7 64-Bit)

Code-Snippet A:

import java.awt.geom.RoundRectangle2D; 

public class Test { 
    private static final RoundRectangle2D.Double RECTANGLE = new RoundRectangle2D.Double(1, 2, 3, 4, 5, 6); 

    public static void main(String[] args) { 
     int result = RECTANGLE.hashCode(); 
     long start = System.nanoTime(); 
     for (int i = 0; i < 100_000_000; i++) { 
      result += RECTANGLE.hashCode();   // <= Only change is on this line 
     } 
     System.out.println((System.nanoTime() - start)/1_000_000); 
     System.out.println(result); 
    } 
} 

-Code-Schnipsel B:

import java.awt.geom.RoundRectangle2D; 

public class Test { 
    private static final RoundRectangle2D.Double RECTANGLE = new RoundRectangle2D.Double(1, 2, 3, 4, 5, 6); 

    public static void main(String[] args) { 
     int result = RECTANGLE.hashCode(); 
     long start = System.nanoTime(); 
     for (int i = 0; i < 100_000_000; i++) { 
      result += new RoundRectangle2D.Double(1, 2, 3, 4, 5, 6).hashCode(); 
     } 
     System.out.println((System.nanoTime() - start)/1_000_000); 
     System.out.println(result); 
    } 
} 

TL; DR: die Verwendung von new Schlüsselwort innerhalb einer Schleife ist schneller als ein static final Feld zugreifen.

(Anmerkung: Das Entfernen der final Schlüsselwort auf RECTANGLE nicht die Ausführungszeit ändern)

Answer 1

Im ersten Fall (static final) JVM benötigt Objektfelder aus dem Speicher zu lesen. Im zweiten Fall ist bekannt, dass die Werte konstant sind. Da das Objekt nicht aus der Schleife austritt, wird außerdem die Zuweisung eliminiert, z. Seine Felder werden durch lokale Variablen ersetzt.

Die folgende JMH Benchmark unterstützt die Theorie:

package bench; 

import org.openjdk.jmh.annotations.*; 
import java.awt.geom.RoundRectangle2D; 

@State(Scope.Benchmark) 
public class StaticRect { 
    private static final RoundRectangle2D.Double RECTANGLE = 
      new RoundRectangle2D.Double(1, 2, 3, 4, 5, 6); 

    @Benchmark 
    public long baseline() { 
     return 0; 
    } 

    @Benchmark 
    public long testNew() { 
     return new RoundRectangle2D.Double(1, 2, 3, 4, 5, 6).hashCode(); 
    } 

    @Benchmark 
    @Fork(jvmArgs = "-XX:-EliminateAllocations") 
    public long testNewNoEliminate() { 
     return new RoundRectangle2D.Double(1, 2, 3, 4, 5, 6).hashCode(); 
    } 

    @Benchmark 
    public int testStatic() { 
     return RECTANGLE.hashCode(); 
    } 
} 

Ergebnisse:

Benchmark      Mode Cnt Score Error Units 
StaticRect.baseline   avgt 10 2,840 ± 0,048 ns/op 
StaticRect.testNew    avgt 10 2,831 ± 0,011 ns/op 
StaticRect.testNewNoEliminate avgt 10 8,566 ± 0,036 ns/op 
StaticRect.testStatic   avgt 10 12,689 ± 0,057 ns/op 

testNew ist so schnell, wie eine konstante Rückkehr weil Zuordnungsobjekt eliminiert wird und die hashCode konstant falteten während JIT-Zusammenstellung.

Wenn EliminateAllocations Optimierung deaktiviert ist, ist der Maßstab der Zeit deutlich höher, aber die arithmetischen Berechnungen von hashCode sind noch Konstant gefaltet.

In der letzten Benchmark, obwohl RECTANGLE als final deklariert ist, können seine Felder theoretisch geändert werden, sodass JIT den Feldzugriff nicht eliminieren kann.