Take a look at BTrace. You can create a script to get method execution times and run it against your app. Especially if you tell it to log all method calls; keeping in mind the performance penalty, of course. I wrote my script to write out in csv format, and then I opened the log in Libre Office for analysis. On Apr 10, 2016 1:39 PM, "Serega Sheypak" <[email protected]> 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. Probably, my problem a bit similar to this thread: Call site caching faster than invokedynamic? <http://groovy.329449.n5.nabble.com/Call-site-caching-faster-than-invokedynamic-tp5721659p5721674.html> Most of CPU time spent in *org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.doCallSiteTargetSet* 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?
