Java per le prestazioni ciclo

Question

Cosa c'è di meglio nel ciclo for

questo:

for(int i = 0; i<someMethod(); i++) 
{//some code 
} 

o:

int a = someMethod(); 
for(int i = 0; i<a; i++) 
{//some code 
} 

Diciamo solo che someMethod() restituisce qualcosa di grande.

Primo metodo eseguirà someMethod() in ogni ciclo diminuendo così la velocità, secondo è più veloce ma diciamo che ci sono molti cicli simili a applicazione in modo che dichiara una vill variabile consuma più memoria.

Quindi cosa è meglio, o sto solo pensando stupidamente.

Answer 1

Il secondo è migliore, supponendo che someMethod() non abbia side effects.
In realtà memorizza nella cache il valore calcolato da someMethod(), quindi non sarà necessario ricalcolarlo (presupponendo che si tratti di un'opzione relativamente estesa).

Se lo fa (ha effetti collaterali) - i due scatta codice non sono equivalenti - e si dovrebbe fare ciò che è corretto .

Per quanto riguarda la "dimensione per la variabile un" - non è un problema in ogni caso, il ritornato valore someMethod() ha bisogno di essere memorizzati su qualche variabile temporanea intermedia comunque prima del calcolo (e anche se non era il caso, la dimensione di un intero è trascurabile).

P.S.
In alcuni casi, il compilatore/ottimizzatore JIT potrebbe ottimizzare il primo codice nel secondo, presupponendo ovviamente nessun effetto collaterale.

Answer 2

In caso di dubbio, test. Usa un profiler. Misurare.

Answer 3

Supponendo che l'ordine di iterazione non è rilevante, e anche supponendo che si vuole veramente nano-ottimizzare il codice, si può fare questo:

for (int i=someMethod(); i-->0;) { 
    //some code 
} 

Ma una variabile locale supplementare (il vostro a) non è disponibile un tale onere. In pratica, questo non è molto diverso dalla tua seconda versione.

Answer 4

Dipende molto da quanto tempo occorre per generare l'output di someMethod(). Anche l'utilizzo della memoria sarebbe lo stesso, poiché someMethod() deve prima generare l'output e memorizzarlo. Il secondo modo protegge la CPU dal calcolo dello stesso output su ogni loop e non dovrebbe richiedere più memoria. Quindi il secondo è migliore.

Answer 5

Non considererei il consumo di memoria della variabile a come un problema in quanto è un int e richiede 192 bit su una macchina a 64 bit. Quindi preferirei la seconda alternativa in quanto l'efficienza di esecuzione è migliore.

Answer 6

Se non avete bisogno di questa variabile dopo ciclo, non v'è modo semplice per nasconderlo dentro:

for (int count = someMethod(), i = 0; i < count; i++) 
{ 
    // some code 
} 

Answer 7

Se è necessario ottimizzare questo, allora questo è il modo pulito/ovvio per farlo:

int a = someMethod(); 
for (int i = 0; i < a; i++) { 
    //some code 
} 

La versione alternativa suggerita da @dystroy

for (int i=someMethod(); i-->0;) { 
    //some code 
} 

... ha tre problemi.

• Sta iterando nella direzione opposta.

• L'iterazione non è unidirezionale e quindi è meno leggibile. Soprattutto se si ignora la guida allo stile Java e non si mettono gli spazi bianchi dove si suppone.

• Non c'è alcuna prova che il codice sia effettivamente più veloce della versione più idiomatica ... specialmente una volta che il compilatore JIT li ha ottimizzati entrambi. (E anche se la versione meno leggibile è più veloce, la differenza è probabile che sia trascurabile.)

D'altra parte, se someMethod() è costoso (come postulato) poi "sollevamento" la chiamata in modo che è fatto solo una volta è probabile che valga la pena.

Answer 8

La parte più importante dell'ottimizzazione del ciclo è consentire alla JVM di srotolare il ciclo. Per fare ciò nella prima variante deve essere in grado di inline la chiamata a someMethod(). Inlining ha un budget e può essere sballato a un certo punto. Se someMethod() è abbastanza lungo, la JVM può decidere che non gli piaccia essere in linea.

La seconda variante è più utile (al compilatore JIT) e probabilmente funzionerà meglio.

il mio modo per mettere giù il ciclo è: for (int i=0, max=someMethod(); i<max; i++){...}

max non inquina il codice, ci si assicura senza effetti collaterali da più chiamate di someMethod() ed è compatto (singolo liner)