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 <
rsomasunde...@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 <keeganw...@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 <
> rsomasunde...@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 <keeganw...@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 <oru...@gmail.com> wrote:
>>
>>> now thats a more realistic benchmark.
>>>
>>> Owen Rubel
>>> 415-971-0976
>>> oru...@gmail.com
>>>
>>> On Fri, Jul 10, 2015 at 5:51 PM, Keegan Witt <keeganw...@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 <
>>>> rsomasunde...@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.
>
