groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keegan Witt <keeganw...@gmail.com>
Subject Re: Suggestions for performance improvement
Date Mon, 13 Jul 2015 03:24:28 GMT
Could you share your code changes?  I want to make sure I'm understanding
the current state correctly before answering.

On Sat, Jul 11, 2015 at 11:57 PM, Rahul Somasunderam <
rsomasunderam@transcendinsights.com> wrote:

>  Thanks Keegan, I moved my static compilation methods to GApplication and
> balanced that out.
> Once I did that, GProf suddenly started profiling my code. At least it
> tells me where time was spent. Alas, it doesn't tell me why so much time
> was spent that in running groovy code that calls java code.
>
>                               user  system     cpu    real
>
> JApplication.java             808       2     810     813
> Application.java           390499    1300  391799  400135
> GApplication.javaStatic    268952     856  269808  274687
> Application.groovy         789352    1457  790809  801440
> GApplication.groovyStatic  401750    2191  403941  411604
> Flat:
>
>  %    cumulative   self            self     total    self    total   self
>   total
> time   seconds    seconds  calls  ms/call  ms/call  min ms  min ms  max
> ms  max ms  name
> 60.4        0.00     0.00      1     0.45     0.74    0.45    0.74
>   0.45    0.74  main.Application$_main_closure2.doCall
> 39.5        0.00     0.00      1     0.29     0.29    0.29    0.29
>   0.29    0.29  main.GApplication.javaStatic
>
> Call graph:
>
> index  % time  self  children  calls  name
>
>                0.00      0.00    1/1      <spontaneous>
>
> [1]     100.0  0.00      0.00
>   1  main.Application$_main_closure2.doCall [1]
>                0.00      0.00    1/1      main.GApplication.javaStatic
> [2]
>
> ------------------------------------------------------------------------------------
>                0.00      0.00    1/1
>   main.Application$_main_closure2.doCall [1]
> [2]      39.5  0.00      0.00      1  main.GApplication.javaStatic [2]
>
>
> ------------------------------------------------------------------------------------
> Flat:
>
>  %    cumulative   self            self     total    self    total   self
>   total
> time   seconds    seconds  calls  ms/call  ms/call  min ms  min ms  max
> ms  max ms  name
> 84.3        0.00     0.00      1     0.09     0.11    0.09    0.11
>   0.09    0.11  main.Application$_main_closure3.doCall
> 15.6        0.00     0.00      1     0.01     0.01    0.01    0.01
>   0.01    0.01  main.JApplication.java
>
> Call graph:
>
> index  % time  self  children  calls  name
>
>                0.00      0.00    1/1      <spontaneous>
>
> [1]     100.0  0.00      0.00
>   1  main.Application$_main_closure3.doCall [1]
>                0.00      0.00    1/1      main.JApplication.java [2]
>
>
> ------------------------------------------------------------------------------------
>                0.00      0.00    1/1
>   main.Application$_main_closure3.doCall [1]
> [2]      15.6  0.00      0.00      1  main.JApplication.java [2]
>
>
> ------------------------------------------------------------------------------------
>
> The first block of profile output is for GApplication.javaStatic, where as
> the second is for JApplication.java
>
>  R,
> rahul
>
>
> *Rahul Somasunderam *
>
> *Engineer, Transcend Insights *
>
>  On Jul 11, 2015, at 7:54 PM, Keegan Witt <keeganwitt@gmail.com> wrote:
>
>  Well, for one thing, *Application* is not completely statically
> compiled.  So there is still overhead introduced that is not present in the
> pure Java version.
>
> As for your StackOverflow, I'm not really sure what to recommend, as I've
> not used GProf.  I guess raising an issue on their GitHub page would be one
> way of getting help from their devs.  I didn't see any mailing lists.
>
>  -Keegan
>
> On Sat, Jul 11, 2015 at 12:24 AM, Rahul Somasunderam <
> rsomasunderam@transcendinsights.com> wrote:
>
>>  Hi Keegan,
>>
>>  Thanks for your help. The groovy static code runs almost as fast as the
>> java code when invoked from groovy code.
>>
>>  I went from this:
>>
>>                                  user  system     cpu    real
>>
>>      JApplication.java            668       0     668     668
>>     Application.java          365631     813  366444  371535
>>     Application.javaStatic    240292     405  240697  244008
>>     Application.groovy        787992    1005  788997  799195
>>     Application.groovyStatic  650475     985  651460  665035
>>
>>  to:
>>
>>                                  user  system     cpu    real
>>
>>      JApplication.java            718       0     718     719
>>     Application.java          359312     610  359922  364478
>>     Application.javaStatic    252557     578  253135  256752
>>     Application.groovy        735788     982  736770  746124
>>     Application.groovyStatic  341818     559  342377  348514
>>
>>  I decided to stop calling groovy code from java code, because that is
>> not my problem, and so gradle still works. And this works too:
>>
>>      ./gradlew run
>>
>> What I'm wondering why the java code calling java code is so much faster
>> than groovy code calling java code.
>>
>>  @tim_yates recommended running a gprof on my code, but that seems to
>> consistently run into a StackOverflowError.
>> In my main method, I wrote this
>>
>>      profile {
>>         Application.javaStatic(300)
>>     }.prettyPrint()
>>
>>  This is the stack trace
>>
>>      Exception in thread "main" java.lang.StackOverflowError
>>     at java.lang.Class.forName(Class.java:348)
>>     at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray$1.run(CallSiteArray.java:65)
>>     at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray$1.run(CallSiteArray.java:62)
>>     at java.security.AccessController.doPrivileged(Native Method)
>>     at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallStaticSite(CallSiteArray.java:62)
>>     at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite(CallSiteArray.java:159)
>>     at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
>>     at
>> org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:55)
>>     at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
>>     at
>> org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:55)
>>     at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
>>     at
>> org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:55)
>>     at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
>>
>>  Does that look like something I should raise a bug for?
>>
>>  R,
>> rahul
>>
>> *Rahul Somasunderam *
>>
>> *Engineer, Transcend Insights *
>>
>>   On Jul 10, 2015, at 7:26 PM, Keegan Witt <keeganwitt@gmail.com> wrote:
>>
>>  Actually, I started thinking: I introduced the reverse problem Rahul
>> had -- I mixed statically compiled code into the dynamic test.  That's why
>> the difference between static and dynamic Groovy wasn't that substantial.
>> My last commit fixes that, with these results
>>
>>                              user  system      cpu     real
>>
>> JApplication.java             405       0      405      431
>> JApplication.groovy           639       0      639      651
>> Application.java          1088350      20  1088370  1144546
>> Application.javaStatic     707835      15   707850   895170
>> Application.groovy        2333817      38  2333855  2492637
>> Application.groovyStatic   736772      11   736783   857732
>>
>> On Fri, Jul 10, 2015 at 8:58 PM, Owen Rubel <orubel@gmail.com> wrote:
>>
>>> now thats a more realistic benchmark.
>>>
>>> Owen Rubel
>>> 415-971-0976
>>> orubel@gmail.com
>>>
>>> On Fri, Jul 10, 2015 at 5:51 PM, Keegan Witt <keeganwitt@gmail.com>
>>> wrote:
>>>
>>>>  Hi Rahul,
>>>>  One issue is that your GroovyStatic test is mixing statically compiled
>>>> and non-statically compiled clases.  I changed the GroovyPlain classes to
>>>> be compiled statically, and the results went from
>>>>
>>>>                              user  system      cpu     real
>>>>
>>>> JApplication.java             433       0      433      433
>>>> JApplication.groovy           646       0      646      655
>>>> Application.java           963173   18907   982080  1131540
>>>> Application.javaStatic     750500      14   750514   853262
>>>> Application.groovy        2541527      41  2541568  2607827
>>>> Application.groovyStatic  2006609      30  2006639  2049778
>>>>
>>>>  to
>>>>
>>>>                              user  system      cpu     real
>>>>
>>>> JApplication.java             411       0      411      411
>>>> JApplication.groovy           561       0      561      585
>>>> Application.java          1021404      21  1021425  1097055
>>>> Application.javaStatic     759105      15   759120   826062
>>>> Application.groovy         922849      17   922866  1088130
>>>> Application.groovyStatic   762211       3   762214   822157
>>>>
>>>>  I experienced the Gradle issue as well.  I'm too tired to think right
>>>> now if there's a workaround, but in the mean time GMavenPlus works just
>>>> fine.  You can see my changes on my fork:
>>>> https://github.com/keeganwitt/perfcomp
>>>>
>>>>  -Keegan
>>>>
>>>> On Fri, Jul 10, 2015 at 3:33 PM, Rahul Somasunderam <
>>>> rsomasunderam@transcendinsights.com> wrote:
>>>>
>>>>> Here's a project i've setup to run some tests -
>>>>> https://github.com/rahulsom/perfcomp
>>>>> The code is based on Mr Haki's
>>>>> http://mrhaki.blogspot.com/2009/09/groovy-goodness-multimethods-or.html
>>>>>
>>>>>  This is the result of running my tests
>>>>>
>>>>>  Environment
>>>>> ===========
>>>>> * Groovy: 2.4.3
>>>>> * JVM: Java HotSpot(TM) 64-Bit Server VM (25.31-b07, Oracle
>>>>> Corporation)
>>>>>     * JRE: 1.8.0_31
>>>>>     * Total Memory: 123 MB
>>>>>     * Maximum Memory: 1820.5 MB
>>>>> * OS: Mac OS X (10.9.5, x86_64)
>>>>>
>>>>>  Options
>>>>> =======
>>>>> * Warm Up: Auto (- 60 sec)
>>>>> * CPU Time Measurement: On
>>>>>
>>>>>                              user  system     cpu    real
>>>>>
>>>>>  JApplication.java             13       0      13      13
>>>>> JApplication.groovy           94       0      94     100
>>>>> Application.java          426181    1584  427765  429254
>>>>> Application.javaStatic    288418     918  289336  290410
>>>>> Application.groovy        832317    2360  834677  837481
>>>>> Application.groovyStatic  687717    2024  689741  697543
>>>>>
>>>>>  It looks like when Java executes the code, it's several orders of
>>>>> magnitude faster. Is there an option I can try tuning to improve groovy's
>>>>> odds in this comparison?
>>>>> I could get IDEA to run my Application.groovy. I couldn't get gradle
>>>>> to do that, possibly because there's java code depending on groovy code
and
>>>>> groovy code depending on java code. Please ignore that if you want to
play
>>>>> with the project.
>>>>>
>>>>>  Appreciate any help/advice.
>>>>>
>>>>>  R,
>>>>> rahul
>>>>>
>>>>>
>>>>> *Rahul Somasunderam *
>>>>>
>>>>> *Engineer, Transcend Insights *
>>>>>
>>>>>
>>>>> The information transmitted is intended only for the person or entity
>>>>> to which it is addressed
>>>>> and may contain CONFIDENTIAL material. If you receive this
>>>>> material/information in error,
>>>>> please contact the sender and delete or destroy the
>>>>> material/information.
>>>>>
>>>>
>>>>
>>>
>>
>>
>> The information transmitted is intended only for the person or entity to
>> which it is addressed
>> and may contain CONFIDENTIAL material. If you receive this
>> material/information in error,
>> please contact the sender and delete or destroy the material/information.
>>
>
>
>
> The information transmitted is intended only for the person or entity to
> which it is addressed
> and may contain CONFIDENTIAL material. If you receive this
> material/information in error,
> please contact the sender and delete or destroy the material/information.
>

Mime
View raw message