> org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.doC
allSiteTargetSet
I see this method after switching to indy version with invkoedynamic
> That is a hint, that you have a lot of invalid callsites going on
What does it mean? What can I do in order fix it?
>Those are all strings?
Script template is:
def evaluateExpression(Map context){
def user = context.user
%s}
dynamically substituted expression could contain anything
user.attr1 == '1' || user.attr2 == '2' || user.attr3 = '3'
user object holds info about a user doing something online. attr1, attr2,
attr3 could returns various types. Sometimes they return object and I
override returned object equals method.
For example, 'user' object has method:
LastPage getLastPage(){
def attr = getLatestAttribute(PAGE)
if(attr){
lastPage = attr.value
}
new LastPage(lastPage: lastPage)
}
then you can write expression:
user.lastPage == 'somePageRegEx/.*' when you want to get true if user last
page mathes provided regex.
Here is LastPage impl:
class LastPage {
String lastPage
@Override
String toString(){
lastPage
}
@Override
int hashCode(){
1
}
@Override
boolean equals(Object object){
if(object == null || !(object instanceof String || object
instanceof LastPage)){
return false
}
if(object instanceof LastPage){
lastPage.equals(object.lastPage)
}
else{
Pattern pattern = Pattern.compile((String)object)
lastPage ==~ pattern
}
}
}
2016-04-10 20:37 GMT+02:00 Jochen Theodorou <[email protected]>:
> 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
>
>
>
