Se è possibile eliminare i potenziali artefatti dal tempo di avvio come suggerisce Jim, azzarderei quindi un'ipotesi che lo stile Java per il ciclo in Groovy non sia così ben implementato come lo stile originale per ciclo di Groovy. È stato aggiunto solo a partire dalla v1.5 dopo le richieste degli utenti, quindi forse la sua implementazione è stata un po 'ripensata.
Hai dato un'occhiata al bytecode generato per i tuoi due esempi per vedere se ci sono delle differenze? C'è stata una discussione su prestazioni Groovy here in cui uno dei commenti (da un 'johnchase') dice:
Mi chiedo se la differenza avete visto legato al modo in Groovy utilizza i numeri (primitive) - dal momento che avvolge tutti i primitivi nelle loro equivalenti classi di wrapper Java (int -> Integer), immagino che rallenterebbero un po 'le cose. Sarei interessato a vedere le prestazioni del codice Java che esegue il ciclo di 10.000.000 utilizzando le classi wrapper invece di ints.
Quindi forse il loop originale di Groovy non ne risente? Solo speculazioni da parte mia, però.
Questo quasi certamente lo spiega. So che lo stile Java per ciclo offre maggiore flessibilità in ciò che si può fare, ma sicuramente avrebbero potuto applicare qualche ottimizzazione alla sua forma più basilare (e più comunemente usata) in modo che eseguisse sia il ciclo for..in? Questa è una piccola trappola per le prestazioni per le persone che arrivano da Java o C# ... – Xiaofu
Nessuno si aspetta mai questa disparità in queste due operazioni. Aree in cui Groovy potrebbe migliorare, soprattutto perché un codice simile in Java viene eseguito in 300 mS. –
+1 per osservare il bytecode. – Leonel