You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Rahul Somasunderam <rs...@transcendinsights.com> on 2015/07/10 21:33:53 UTC
Suggestions for performance improvement
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.
Re: Suggestions for performance improvement
Posted by Rahul Somasunderam <rs...@transcendinsights.com>.
Thanks! I've created a JIRA to address the performance - https://issues.apache.org/jira/browse/GROOVY-7508
Rahul Somasunderam
Engineer, Transcend Insights
On Jul 18, 2015, at 10:31 AM, Keegan Witt <ke...@gmail.com>> wrote:
a) Not exactly. In an earlier version of the code Rahul was experimenting with to compare performance, he said "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." I was curious about how that could be solved, since GMavenPlus doesn't experience that issue. Maybe I should have started a new thread.
b) It's not perfect, but the solution was to let Groovy compile both the Groovy and the Java, which Peter does in his first sourceSets example. But if anybody has a better idea, I'd love to hear about it. Here's a simple project demonstrating the issue: https://github.com/keeganwitt/circular-gradle
-Keegan
On Sat, Jul 18, 2015 at 12:52 PM, Jochen Theodorou <bl...@gmx.org>> wrote:
a) wrong thread? Or should I say: I miss why your post is a reply to my post
b) what exactly is there a solution to the circular compilation issue?
bye blackdrag
Am 18.07.2015 18:38, schrieb Keegan Witt:
FYI, Peter Niederwieser offered
<http://stackoverflow.com/a/22164339/160256> a solution to the circular
compilation issue about a year ago.
-Keegan
On Tue, Jul 14, 2015 at 1:11 AM, Jochen Theodorou <bl...@gmx.org>
<ma...@gmx.org>>> wrote:
Am 13.07.2015 22:20, schrieb Rahul Somasunderam:
I'm assuming metaclass init should be a one time penalty. Or is
there
something I'm misunderstanding about it?
the big hit is a one time penalty, yes. meta classes might be
created later on again because a meta class might have been garbage
collected on too low memory. But first of all, you have a big hit in
performance caused by reading in the extension methods and created
the basic meta class infrastructure
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
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.
Re: Suggestions for performance improvement
Posted by Keegan Witt <ke...@gmail.com>.
Correct, it's not new.
-Keegan
On Jul 19, 2015 2:06 AM, "Jochen Theodorou" <bl...@gmx.org> wrote:
> Am 18.07.2015 19:31, schrieb Keegan Witt:
>
>> a) Not exactly. In an earlier version of the code Rahul was
>> experimenting with to compare performance, he said "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." I was curious
>> about how that could be solved, since GMavenPlus doesn't experience that
>> issue. Maybe I should have started a new thread.
>>
>
> ok
>
> b) It's not perfect, but the solution was to let Groovy compile both the
>> Groovy and the Java, which Peter does in his first sourceSets example.
>> But if anybody has a better idea, I'd love to hear about it. Here's a
>> simple project demonstrating the issue:
>> https://github.com/keeganwitt/circular-gradle
>>
>
> just to keep the reference: http://stackoverflow.com/a/22164339/160256
>
> What I do read is that the first version is 'just' joint compilation and
> the second is just Groovy code depending on Java code. The groovy gradle
> plugin already supports joint compilation, but looking at the documentation
> about the project layout:
> '''
> src/main/groovy
>
> Production Groovy sources. May also contain Java sources for joint
> compilation.
> '''
>
> so understood his comments, that its about making joint compilation work
> with a different source set only.
>
> That would mean it is no new solution... which I hoped for when I did read
> your mail. Or did I miss something?
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> blog: http://blackdragsview.blogspot.com/
>
>
Re: Suggestions for performance improvement
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 18.07.2015 19:31, schrieb Keegan Witt:
> a) Not exactly. In an earlier version of the code Rahul was
> experimenting with to compare performance, he said "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." I was curious
> about how that could be solved, since GMavenPlus doesn't experience that
> issue. Maybe I should have started a new thread.
ok
> b) It's not perfect, but the solution was to let Groovy compile both the
> Groovy and the Java, which Peter does in his first sourceSets example.
> But if anybody has a better idea, I'd love to hear about it. Here's a
> simple project demonstrating the issue:
> https://github.com/keeganwitt/circular-gradle
just to keep the reference: http://stackoverflow.com/a/22164339/160256
What I do read is that the first version is 'just' joint compilation and
the second is just Groovy code depending on Java code. The groovy gradle
plugin already supports joint compilation, but looking at the
documentation about the project layout:
'''
src/main/groovy
Production Groovy sources. May also contain Java sources for joint
compilation.
'''
so understood his comments, that its about making joint compilation work
with a different source set only.
That would mean it is no new solution... which I hoped for when I did
read your mail. Or did I miss something?
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
Re: Suggestions for performance improvement
Posted by Keegan Witt <ke...@gmail.com>.
a) Not exactly. In an earlier version of the code Rahul was experimenting
with to compare performance, he said "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." I was curious about how that could be solved,
since GMavenPlus doesn't experience that issue. Maybe I should have
started a new thread.
b) It's not perfect, but the solution was to let Groovy compile both the
Groovy and the Java, which Peter does in his first sourceSets example. But
if anybody has a better idea, I'd love to hear about it. Here's a simple
project demonstrating the issue:
https://github.com/keeganwitt/circular-gradle
-Keegan
On Sat, Jul 18, 2015 at 12:52 PM, Jochen Theodorou <bl...@gmx.org>
wrote:
> a) wrong thread? Or should I say: I miss why your post is a reply to my
> post
> b) what exactly is there a solution to the circular compilation issue?
>
> bye blackdrag
>
> Am 18.07.2015 18:38, schrieb Keegan Witt:
>
>> FYI, Peter Niederwieser offered
>> <http://stackoverflow.com/a/22164339/160256> a solution to the circular
>> compilation issue about a year ago.
>>
>> -Keegan
>>
>> On Tue, Jul 14, 2015 at 1:11 AM, Jochen Theodorou <blackdrag@gmx.org
>> <ma...@gmx.org>> wrote:
>>
>> Am 13.07.2015 22:20, schrieb Rahul Somasunderam:
>>
>> I'm assuming metaclass init should be a one time penalty. Or is
>> there
>> something I'm misunderstanding about it?
>>
>>
>> the big hit is a one time penalty, yes. meta classes might be
>> created later on again because a meta class might have been garbage
>> collected on too low memory. But first of all, you have a big hit in
>> performance caused by reading in the extension methods and created
>> the basic meta class infrastructure
>>
>>
>> bye blackdrag
>>
>> --
>> Jochen "blackdrag" Theodorou
>> blog: http://blackdragsview.blogspot.com/
>>
>>
>>
>
> --
> Jochen "blackdrag" Theodorou
> blog: http://blackdragsview.blogspot.com/
>
>
Re: Suggestions for performance improvement
Posted by Jochen Theodorou <bl...@gmx.org>.
a) wrong thread? Or should I say: I miss why your post is a reply to my post
b) what exactly is there a solution to the circular compilation issue?
bye blackdrag
Am 18.07.2015 18:38, schrieb Keegan Witt:
> FYI, Peter Niederwieser offered
> <http://stackoverflow.com/a/22164339/160256> a solution to the circular
> compilation issue about a year ago.
>
> -Keegan
>
> On Tue, Jul 14, 2015 at 1:11 AM, Jochen Theodorou <blackdrag@gmx.org
> <ma...@gmx.org>> wrote:
>
> Am 13.07.2015 22:20, schrieb Rahul Somasunderam:
>
> I'm assuming metaclass init should be a one time penalty. Or is
> there
> something I'm misunderstanding about it?
>
>
> the big hit is a one time penalty, yes. meta classes might be
> created later on again because a meta class might have been garbage
> collected on too low memory. But first of all, you have a big hit in
> performance caused by reading in the extension methods and created
> the basic meta class infrastructure
>
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> blog: http://blackdragsview.blogspot.com/
>
>
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
Re: Suggestions for performance improvement
Posted by Keegan Witt <ke...@gmail.com>.
FYI, Peter Niederwieser offered <http://stackoverflow.com/a/22164339/160256> a
solution to the circular compilation issue about a year ago.
-Keegan
On Tue, Jul 14, 2015 at 1:11 AM, Jochen Theodorou <bl...@gmx.org> wrote:
> Am 13.07.2015 22:20, schrieb Rahul Somasunderam:
>
>> I'm assuming metaclass init should be a one time penalty. Or is there
>> something I'm misunderstanding about it?
>>
>
> the big hit is a one time penalty, yes. meta classes might be created
> later on again because a meta class might have been garbage collected on
> too low memory. But first of all, you have a big hit in performance caused
> by reading in the extension methods and created the basic meta class
> infrastructure
>
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> blog: http://blackdragsview.blogspot.com/
>
>
Re: Suggestions for performance improvement
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 13.07.2015 22:20, schrieb Rahul Somasunderam:
> I'm assuming metaclass init should be a one time penalty. Or is there
> something I'm misunderstanding about it?
the big hit is a one time penalty, yes. meta classes might be created
later on again because a meta class might have been garbage collected on
too low memory. But first of all, you have a big hit in performance
caused by reading in the extension methods and created the basic meta
class infrastructure
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
Re: Suggestions for performance improvement
Posted by Rahul Somasunderam <rs...@transcendinsights.com>.
I'm assuming metaclass init should be a one time penalty. Or is there something I'm misunderstanding about it?
Rahul Somasunderam
Engineer, Transcend Insights
On Jul 13, 2015, at 11:46 AM, Jochen Theodorou <bl...@gmx.org>> wrote:
Am 13.07.2015 20:43, schrieb Keegan Witt:
Hmm, that is interesting. I tried swapping count.times with for loops
(just to be sure it's an apples to apples comparison) and switching to
the indy version of Groovy, but it made no significant difference. The
only other thing that comes to mind is I wonder if metaclass
initialization carries more overhead than I realized. Lemme give it
some more thought / digging.
meta class init is a huge overhead
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
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.
Re: Suggestions for performance improvement
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 13.07.2015 20:43, schrieb Keegan Witt:
> Hmm, that is interesting. I tried swapping count.times with for loops
> (just to be sure it's an apples to apples comparison) and switching to
> the indy version of Groovy, but it made no significant difference. The
> only other thing that comes to mind is I wonder if metaclass
> initialization carries more overhead than I realized. Lemme give it
> some more thought / digging.
meta class init is a huge overhead
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
Re: Suggestions for performance improvement
Posted by Keegan Witt <ke...@gmail.com>.
Hmm, that is interesting. I tried swapping count.times with for loops
(just to be sure it's an apples to apples comparison) and switching to the
indy version of Groovy, but it made no significant difference. The only
other thing that comes to mind is I wonder if metaclass initialization
carries more overhead than I realized. Lemme give it some more thought /
digging.
On Mon, Jul 13, 2015 at 11:53 AM, Rahul Somasunderam <
rsomasunderam@transcendinsights.com> wrote:
> https://github.com/rahulsom/perfcomp
>
> Sorry! Forgot to git push.
> It should be there now.
>
> R,
> rahul
>
>
> *Rahul Somasunderam *
>
> *Engineer, Transcend Insights *
>
> On Jul 12, 2015, at 8:24 PM, Keegan Witt <ke...@gmail.com> wrote:
>
> 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 <ke...@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 <ke...@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 <or...@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 <ke...@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.
>>
>
>
>
> 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.
>
Re: Suggestions for performance improvement
Posted by Rahul Somasunderam <rs...@transcendinsights.com>.
https://github.com/rahulsom/perfcomp
Sorry! Forgot to git push.
It should be there now.
R,
rahul
Rahul Somasunderam
Engineer, Transcend Insights
On Jul 12, 2015, at 8:24 PM, Keegan Witt <ke...@gmail.com>> wrote:
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 <rs...@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 <ke...@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 <rs...@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 <ke...@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 <or...@gmail.com>> wrote:
now thats a more realistic benchmark.
Owen Rubel
415-971-0976<tel:415-971-0976>
orubel@gmail.com<ma...@gmail.com>
On Fri, Jul 10, 2015 at 5:51 PM, Keegan Witt <ke...@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 <rs...@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.
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.
Re: Suggestions for performance improvement
Posted by Keegan Witt <ke...@gmail.com>.
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 <ke...@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 <ke...@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 <or...@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 <ke...@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.
>
Re: Suggestions for performance improvement
Posted by Rahul Somasunderam <rs...@transcendinsights.com>.
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 <ke...@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 <rs...@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 <ke...@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 <or...@gmail.com>> wrote:
now thats a more realistic benchmark.
Owen Rubel
415-971-0976<tel:415-971-0976>
orubel@gmail.com<ma...@gmail.com>
On Fri, Jul 10, 2015 at 5:51 PM, Keegan Witt <ke...@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 <rs...@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.
Re: Suggestions for performance improvement
Posted by Keegan Witt <ke...@gmail.com>.
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 <ke...@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 <or...@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 <ke...@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.
>
Re: Suggestions for performance improvement
Posted by Rahul Somasunderam <rs...@transcendinsights.com>.
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 <ke...@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 <or...@gmail.com>> wrote:
now thats a more realistic benchmark.
Owen Rubel
415-971-0976<tel:415-971-0976>
orubel@gmail.com<ma...@gmail.com>
On Fri, Jul 10, 2015 at 5:51 PM, Keegan Witt <ke...@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 <rs...@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.
Re: Suggestions for performance improvement
Posted by Keegan Witt <ke...@gmail.com>.
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 <or...@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 <ke...@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.
>>>
>>
>>
>
Re: Suggestions for performance improvement
Posted by Owen Rubel <or...@gmail.com>.
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 <ke...@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.
>>
>
>
Re: Suggestions for performance improvement
Posted by Keegan Witt <ke...@gmail.com>.
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.
>