Optimierung der Groovy Performance

Question

Ich arbeite an grooviger Code-Optimierung. Ich habe jvisualvm verwendet, um eine Verbindung zur laufenden Anwendung herzustellen und CPU-Samples zu sammeln. Beispiele sagen, dass org.codehaus.groovy.reflection.CachedMethod.inkove die meiste CPU-Zeit benötigt. Ich sehe keine anderen Anwendungsmethoden in Proben.

Was ist der richtige Weg, um in CachedMethod.invoke zu graben und zu verstehen, welche Codezeilen wirklich Leistungsstrafen geben?

Danke.

UPD: I Indy verwenden zu tun, es half mir nicht.

Ich habe nicht versucht, @CompileStatic einzuführen, da ich meine Engpässe vor dem Umschreiben von groovy nach Java finden möchte.

Mein Problem ein bisschen ähnlich zu diesem Thema: Call site caching faster than invokedynamic?

Ich habe einen Code, der dynamisch groovy Skript komponiert. Skriptvorlage sieht so aus:

def evaluateExpression(Map context){ 
    def user = context.user 
    %s 
} 

wo % s ersetzt mit

user.attr1 == '1' || user.attr2 == '2' || user.attr3 = '3' 

Es gibt einen Satz (insgesamt 20) der Ersatz von Datenbanken genommen haben. Der Code erhält Ersatz von DB, erstellt GroovyScript und wertet es aus. Ich nehme an, der Flaschenhals ist in der Skriptausführung. Was ist der richtige Weg, um es zu beheben?

Answer 1

Also, ich habe verschiedene Dinge ausprobiert

1. groovy-indy,
2. groovy-indy nicht mit einiger Code "Optimierung" nicht funktioniert, funktioniert nicht. Übrigens habe ich angefangen, mit try/catch herumzuspielen und dadurch habe ich meinen "Hotspot" 4 mal schneller laufen lassen. Ich bin nicht gut in JVM Interna, aber das Internet sagt - versuchen/fangen verhindert Optimierungen. Ich habe es als eine Grundwahrheit angenommen. Sie müssen tiefer verstehen, wer es wirklich funktioniert.
3. Ich gab auf, aktivierte dynamic und schrieb meinen "heißesten" Code mit @CompileStatic um. Es hat ungefähr 3-4 Stunden gedauert und mein Code läuft jetzt 100 Mal schneller.

Hier sind anfängliche Metriken mit "invokedynamic Unterstützung"

count = 83043 

    mean rate = 395.52 calls/second 

1-minute rate = 555.30 calls/second 

5-minute rate = 217.78 calls/second 

15-minute rate = 82.92 calls/second 

      min = 0.29 milliseconds 

      max = 12.98 milliseconds 

      mean = 1.59 milliseconds 

     stddev = 1.08 milliseconds 

     median = 1.39 milliseconds 

      75% <= 2.46 milliseconds 

      95% <= 3.14 milliseconds 

      98% <= 3.44 milliseconds 

      99% <= 3.76 milliseconds 

     99.9% <= 12.19 milliseconds 

Hier @CompileStatic Metriken sind mit ind ausgeschaltet. Übrigens gibt es keinen Grund, @CompileStatic zu verwenden, wenn "indy" aktiviert ist.

count = 139724 

    mean rate = 8950.43 calls/second 

1-minute rate = 2011.54 calls/second 

5-minute rate = 426.96 calls/second 

15-minute rate = 143.76 calls/second 

      min = 0.02 milliseconds 

      max = 24.18 milliseconds 

      mean = 0.08 milliseconds 

     stddev = 0.72 milliseconds 

     median = 0.06 milliseconds 

      75% <= 0.08 milliseconds 

      95% <= 0.11 milliseconds 

      98% <= 0.15 milliseconds 

      99% <= 0.20 milliseconds 

     99.9% <= 1.27 milliseconds