2010-01-06 11 views
9

C'è una stima che dice quanto JSR-292 avrà un impatto sulle prestazioni di Groovy?Quanto farà JSR-292 (invokedynamic) alle prestazioni di Groovy?

+0

Sembra che ci sia ancora una lunga strada da percorrere per il codice Groovy per ottenere determinati benefici dalle prestazioni invokedynamic. Il mio algoritmo genetico eseguito 5 volte più lento con abilitato invokedynamic, e l'ho testato con Java 1.8.0 e Groovy 2.2.1! Puoi provare da solo, clonare questo: https://github.com/renatoathaydes/MachineLearning ed eseguire test 'com.athaydes.ml.algorithms.LinearGPTest :: testNonTrivialPrograms'. Funziona normalmente in 4 secondi, ma con groovy-indy e invokedynamic, funziona in almeno 25 secondi. – Renato

+0

Un altro post che mostrava anche indy può effettivamente rallentare il tuo codice Groovy: http://derjan.io/blog/2012/08/08/first-steps-with-groovys-invokedynamic-support/ – Renato

risposta

4

invokedynamic è una storia complicata in realtà, dal momento che le caratteristiche di prestazione cambiano tutto il tempo in JDK7. Durante il porting di Groovy a indy sono diventato davvero, molto vicino a Java, circa il fattore 1.5. Ma devo usare catchExceptionGuard, che riduce le prestazioni a qualcosa di simile al fattore 3-4. Dobbiamo ancora studiare i modi per evitare di dover usare quella guardia. Forse dovremo rompere qualche codice esistente in Groovy 2.2 per quello. Ad ogni modo, non ho bisogno della protezione per il fallback invokeMethod come menzionato sopra. È per GroovyRuntimeExceptions possibilmente contenente altre eccezioni, che devo scartare o fare altre cose con. Quindi la prestazione teorica possibile sembra essere tra Java e metà della velocità di Java per i metodi esistenti. L'esecuzione delle chiamate su invokeMethod è una storia completamente diversa.

Se è necessario altro, utilizzare @CompileStatic in Groovy 2.0.

3

Io non credo che ci sia ancora un punto di riferimento, e fino a quando qualcuno compie Possiamo solo immaginare ...

Si possono trovare this post in questa materia interessante.

2

Sarebbe circa 10-50 volte più veloce in generale.

http://www.mail-archive.com/[email protected]/msg00819.html

+1

Puoi tornare indietro? con alcuni riferimenti o prove? –

+0

Ciao, Ho aggiunto il collegamento. Si basa sulla mia esperienza personale nella creazione di un compilatore Groovy su JSR-292. E in fondo, è una stima (come la domanda ha chiesto anche la stima;) – chanwit

+1

Davvero fuorviante. In realtà ho avuto un rallentamento di 5x con indy abilitato. – Renato

0

io non sono sicuro di quanto è applicabile a Groovy. Se ricordo bene, Groovy ha alcuni fallback (ad esempio il metodo invokeMethod). Non è possibile usare semplicemente il fallback con invokedynamic, penso.

Tuttavia, ci sono alcuni modi:

  • intercettare l'eccezione che viene generata quando il metodo non viene trovato. Sfortunatamente, è probabilmente necessario analizzare lo stacktrace, perché non si può essere sicuri da dove viene generato. Questo può essere un rallentamento significativo quando si chiama un metodo non esistente, indipendentemente dal fatto che sia gestito dal callback invokeMethod.
  • Guarda Groovy ++. Ti consente di utilizzare la digitazione statica se soddisfi alcuni vincoli. In tal caso, è possibile consentire di passare a una "modalità dinamica rigorosa", che non consente questi fallback.
Problemi correlati