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 Sun, 12 Jul 2015 02:54:45 GMT
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.
>

Mime
View raw message