Perché la finale statica è più lenta di una nuova su ciascuna iterazione

Question

Perché lo snippet di codice A 14x è più lento dello snippet di codice B?
(testato con jdk1.8.0_60 su Windows 7 64bit)

frammento di codice 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); 
    } 
} 

Codice frammento 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: Utilizzando la La parola chiave new all'interno di un ciclo è più veloce dell'accesso a un campo static final.

(nota: rimozione della parola final su RECTANGLE non modifica il tempo di esecuzione)

Answer 1

Nel primo caso (statica finale) JVM deve leggere campi oggetto dalla memoria. Nel secondo caso i valori sono noti per essere costanti. Inoltre, poiché l'oggetto non esce dal loop, l'allocazione viene eliminata, ad es. i suoi campi sono sostituiti con variabili locali.

Il seguente JMH benchmark sostiene la teoria:

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(); 
    } 
} 

Risultati:

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 è veloce come restituire un costante, perché allocazione oggetto viene eliminato e il hashCode è costante ripiegato durante Compilazione JIT.

Quando l'ottimizzazione EliminateAllocations è disabilitata, il tempo di benchmark è notevolmente più alto, ma i calcoli aritmetici di hashCode sono ancora piegati in modo costante.

Nell'ultimo benchmark, anche se RECTANGLE è dichiarato definitivo, i suoi campi potrebbero essere in teoria modificati, quindi JIT non può eliminare l'accesso al campo.