Groovy: Czy dla ... znacznie szybciej niż .each?

Question

Jestem ciekawy, czy for..in powinien być preferowany do .each ze względu na wydajność.

Answer 1

For .. in jest częścią standardowej kontroli przepływu języka.

Zamiast tego each wywołuje zamknięcie z dodatkowym obciążeniem.

.each {...} cukier jest składnia równoważne wywołaniu metody .each({...})

Ponadto, ze względu na fakt, że jest to zamknięcie, wewnątrz bloku kodu each nie można wykorzystać break i continue sprawozdań do kontroli pętli.

http://kunaldabir.blogspot.it/2011/07/groovy-performance-iterating-with.html

Aktualizacja odniesienia Java 1.8.0_45 Groovy 2.4.3:

• 3327981 każdy {}
• 320949 o() {

Oto inny wzorzec z 100000 iteracje:

lines = (1..100000) 
// with list.each {} 
start = System.nanoTime() 
lines.each { line-> 
    line++; 
} 
println System.nanoTime() - start 

// with loop over list 
start = System.nanoTime() 
for (line in lines){ 
    line++; 
} 
println System.nanoTime() - start 

Wyniki:

• 261062715 każdy {}
• 64518703 do() {}

Answer 2

Rzućmy okiem teoretycznej na rzeczy w kategoriach tego, co połączenia wykonywane są dynamiczne i jakie połączenia są wykonywane więcej bezpośrednio z logiką Java (wywołuję te statyczne wywołania).

W przypadku for-in, Groovy działa na Iteratorze, aby go uzyskać, mamy jedno dynamiczne wywołanie iteratora(). Jeśli się nie mylę, hasNext i następne wywołania są wykonywane przy użyciu zwykłej logiki wywołania metody Java. Tak więc dla każdej iteracji mamy tutaj tylko 2 statyczne wywołania. W zależności od benchmarku należy zauważyć, że to pierwsze wywołanie iterator() może spowodować poważne czasy inicjalizacji, ponieważ może to zainicjować system meta-klasy, a to zajmuje chwilę.

W przypadku each mamy wywołanie dynamiczne do każdego z nich, jak również tworzenie obiektu dla bloku otwartego (wystąpienie zamknięcia). each (Closure) następnie wywoła iterator(), ale uncached ... cóż, wszystkie jednorazowe koszty. Podczas pętli hasNext i dalej są wykonywane przy użyciu logiki Java, która wykonuje 2 statyczne wywołania. Wywołanie do wystąpienia zamknięcia odbywa się za pomocą standardowej logiki java dla wywołania metody, która następnie wywoła metodę doCall za pomocą wywołania dynamicznego.

Podsumowując, za iterację for-in używa tylko 2 wywołania statyczne, a each ma 3 wywołania statyczne i 1 dynamiczne. Wywołanie dynamiczne jest znacznie wolniejsze niż wiele wywołań statycznych i znacznie trudniejsze do optymalizacji pod kątem JVM, tym samym dominując w czasie. W wyniku tego each powinien zawsze być wolniejszy, o ile blok otwarty wymaga wywołania dynamicznego.

Z powodu skomplikowanej logiki wywołania Closure # trudno jest zoptymalizować wywołanie dynamiczne. I to jest denerwujące, ponieważ tak naprawdę nie jest potrzebne i zostanie usunięte, gdy tylko znajdziemy obejście.Jeśli kiedykolwiek nam się to uda, each może nadal działać wolniej, ale jest o wiele trudniejsze, ponieważ odgrywają tu rolę rozmiary kodu bajtowego i profile wywoływania. Teoretycznie mogą być równe (ignorując czas inicjacji), ale JVM ma znacznie więcej pracy do wykonania. Oczywiście to samo dotyczy przykładów strumieniowego przetwarzania lambda w Java8,