On 10.04.2016 19:38, Serega Sheypak wrote:
I'm working on groovy code performance optimization. I've used jvisualvm
to connect to running application and gather CPU samples. Samples say
that/org.codehaus.groovy.reflection.CachedMethod.inkove/ takes the most
CPU time. I don't see any other application methods in samples.
What is the right way to dig into /CachedMethod.invoke/ and understand
what code lines really give performance penalties?
Then I switched to groovy-indy version, now I see different results in
jviusalvm.
I don't think your analysis hits the spot. If you have
def foo(){ bar() }
then there is a time spent in foo itself and the total time for foo,
which is the time spent in foo itself and the time spent in bar.
imagine CachedMethod.invoke to be like that. Are we then really talking
about time spent in invoke itself or does it include the time added
through the method called from there?
[...]
Most of CPU time spent in
*org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.doCallSiteTargetSet*
That is a hint, that you have a lot of invalid callsites going on
I have a code that dynamically composes groovy script. Script template
looks this way:
|def evaluateExpression(Map context){def user = context.user %s }|
where *%s* replaced with
|user.attr1 =='1'||user.attr2 =='2'||user.attr3 ='3'|
There is a set (20 in total) of replacements have taken from Databases.
The code gets replacements from DB, creates GroovyScript and evaluates
it. I suppose the bottleneck is in the script execution. What is the
right way to fix it?
Those are all strings?
bye Jochen
