Return-Path: X-Original-To: apmail-groovy-users-archive@minotaur.apache.org Delivered-To: apmail-groovy-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AB22E17EE5 for ; Sun, 12 Jul 2015 03:59:12 +0000 (UTC) Received: (qmail 21491 invoked by uid 500); 12 Jul 2015 03:59:07 -0000 Delivered-To: apmail-groovy-users-archive@groovy.apache.org Received: (qmail 21458 invoked by uid 500); 12 Jul 2015 03:59:07 -0000 Mailing-List: contact users-help@groovy.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@groovy.incubator.apache.org Delivered-To: mailing list users@groovy.incubator.apache.org Received: (qmail 21448 invoked by uid 99); 12 Jul 2015 03:59:07 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Jul 2015 03:59:07 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id E742AD3DA2 for ; Sun, 12 Jul 2015 03:59:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 5 X-Spam-Level: ***** X-Spam-Status: No, score=5 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=3, KAM_LAZY_DOMAIN_SECURITY=1, KAM_LIVE=1, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id ifuCjB4w--qZ for ; Sun, 12 Jul 2015 03:58:54 +0000 (UTC) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.197]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id B24B343BB0 for ; Sun, 12 Jul 2015 03:58:54 +0000 (UTC) Received: from [216.82.242.131] by server-5.bemta-8.messagelabs.com id CE/BC-01833-CB5E1A55; Sun, 12 Jul 2015 03:57:48 +0000 X-Env-Sender: rsomasunderam@transcendinsights.com X-Msg-Ref: server-14.tower-76.messagelabs.com!1436673467!35591020!1 X-Originating-IP: [205.145.64.115] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=transcendinsights.com,-,- X-VirusChecked: Checked Received: (qmail 29098 invoked from network); 12 Jul 2015 03:57:48 -0000 Received: from outbound1.humana.com (HELO LOUAXP02.rsc.humad.com) (205.145.64.115) by server-14.tower-76.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Jul 2015 03:57:48 -0000 X-WSS-ID: 0NRCWCC-02-9HO-02 X-M-MSG: Received: from pobox.humana.com (unknown [193.41.152.240]) by LOUAXP02.rsc.humad.com (Postfix) with ESMTP id 2DAA958297D for ; Sat, 11 Jul 2015 23:57:48 -0400 (EDT) Received: from LOUMBXWPG01S01.rsc.humad.com ([169.254.1.8]) by LOUMHTWPS03.rsc.humad.com ([193.41.152.32]) with mapi id 14.03.0235.001; Sat, 11 Jul 2015 23:57:45 -0400 From: Rahul Somasunderam To: "users@groovy.incubator.apache.org" Subject: Re: Suggestions for performance improvement Thread-Topic: Suggestions for performance improvement Thread-Index: AQHQu0daVv9R4tPwbU2QFugmttsDOp3VtAUAgAABzACAABiogIAAIRQAgAF5KYCAABFNAA== Date: Sun, 12 Jul 2015 03:57:44 +0000 Message-ID: References: <3993288B-8C9B-46C0-8F03-F86CB796310A@humana.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.41.152.240] Content-Type: multipart/alternative; boundary="_000_E7569214588C4D58946DC514D4382AB7humanacom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected --_000_E7569214588C4D58946DC514D4382AB7humanacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Keegan, I moved my static compilation methods to GApplication and b= alanced that out. Once I did that, GProf suddenly started profiling my code. At least it tel= ls 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= =20 0.29 main.GApplication.javaStatic Call graph: index % time self children calls name 0.00 0.00 1/1 [1] 100.0 0.00 0.00 1 main.Application$_main_closure2.doCa= ll [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 [1] 100.0 0.00 0.00 1 main.Application$_main_closure3.doCa= ll [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 > wrote: Well, for one thing, Application is not completely statically compiled. S= o 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 on= e 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 > wrote: Hi Keegan, Thanks for your help. The groovy static code runs almost as fast as the ja= va 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 t= han groovy code calling java code. @tim_yates recommended running a gprof on my code, but that seems to consi= stently 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(CallSiteAr= ray.java:65) at org.codehaus.groovy.runtime.callsite.CallSiteArray$1.run(CallSiteAr= ray.java:62) at java.security.AccessController.doPrivileged(Native Method) at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallStatic= Site(CallSiteArray.java:62) at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite(C= allSiteArray.java:159) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(Call= SiteArray.java:45) at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(Stati= cMetaClassSite.java:55) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(Call= SiteArray.java:45) at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(Stati= cMetaClassSite.java:55) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(Call= SiteArray.java:45) at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(Stati= cMetaClassSite.java:55) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(Call= SiteArray.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 > 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 > 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 > 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 =20759105 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 > wrote: Here's a project i've setup to run some tests - https://github.com/rahulso= m/perfcomp The code is based on Mr Haki's http://mrhaki.blogspot.com/2009/09/groovy-g= oodness-multimethods-or.html This is the result of running my tests Environment =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * 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 =3D=3D=3D=3D=3D=3D=3D * 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 magnitud= e 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 gro= ovy code depending on java code. Please ignore that if you want to play wi= th 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 w= hich it is addressed and may contain CONFIDENTIAL material. If you receive this material/inform= ation 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 w= hich it is addressed and may contain CONFIDENTIAL material. If you receive this material/inform= ation 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 w= hich it is addressed and may contain CONFIDENTIAL material. If you receive this material/infor= mation in error, please contact the sender and delete or destroy the material/information. --_000_E7569214588C4D58946DC514D4382AB7humanacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <08D2AB0884C87849A84BD341C15A7D96@humana.com> Content-Transfer-Encoding: quoted-printable Thanks Keegan, I moved my static compilation methods to GApplication and b= alanced that out.
Once I did that, GProf suddenly started profiling my code. At least i= t 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  sy= stem     cpu    real

JApplication.java             808&= nbsp;      2     810   &= nbsp; 813
Application.java           390499 =   1300  391799  400135
GApplication.javaStatic    268952     8= 56  269808  274687
Application.groovy         789352  &nbs= p; 1457  790809  801440
GApplication.groovyStatic  401750    2191 &n= bsp;403941  411604
Flat:

 %    cumulative   self    &n= bsp;       self     total  &n= bsp; self    total   self   &= nbsp;total                 &n= bsp;                    =  
time   seconds    seconds  calls&n= bsp; ms/call  ms/call  min ms  min ms&n= bsp; max ms  max ms  name     &nbs= p;                     &= nbsp;      
60.4        0.00     0.00&nbs= p;     1     0.45    &nb= sp;0.74    0.45    0.74    0.= 45    0.74  main.Application$_main_closure2.doCal= l
39.5        0.00     0.00&nbs= p;     1     0.29    &nb= sp;0.29    0.29    0.29    0.= 29    0.29  main.GApplication.javaStatic &nb= sp;        

Call graph:

index  % time  self  children  cal= ls  name               &= nbsp;                    = ;      
               0.00    &= nbsp; 0.00    1/1      <spontan= eous>                  &nb= sp;          
[1]     100.0  0.00      = ;0.00      1  main.Application$_main_closure= 2.doCall [1]    
               0.00    &= nbsp; 0.00    1/1      main.GAppli= cation.javaStatic [2]          
--------------------------------------------------------------------------= ----------
               0.00    &= nbsp; 0.00    1/1      main.Applic= ation$_main_closure2.doCall [1]
[2]      39.5  0.00      = ;0.00      1  main.GApplication.javaStatic [= 2]              
--------------------------------------------------------------------------= ----------
Flat:

 %    cumulative   self    &n= bsp;       self     total  &n= bsp; self    total   self   &= nbsp;total                 &n= bsp;                    =  
time   seconds    seconds  calls&n= bsp; ms/call  ms/call  min ms  min ms&n= bsp; max ms  max ms  name     &nbs= p;                     &= nbsp;      
84.3        0.00     0.00&nbs= p;     1     0.09    &nb= sp;0.11    0.09    0.11    0.= 09    0.11  main.Application$_main_closure3.doCal= l
15.6        0.00     0.00&nbs= p;     1     0.01    &nb= sp;0.01    0.01    0.01    0.= 01    0.01  main.JApplication.java   &n= bsp;            

Call graph:

index  % time  self  children  cal= ls  name               &= nbsp;                    = ;      
               0.00    &= nbsp; 0.00    1/1      <spontan= eous>                  &nb= sp;          
[1]     100.0  0.00      = ;0.00      1  main.Application$_main_closure= 3.doCall [1]    
               0.00    &= nbsp; 0.00    1/1      main.JAppli= cation.java [2]               &nbs= p;
--------------------------------------------------------------------------= ----------
               0.00    &= nbsp; 0.00    1/1      main.Applic= ation$_main_closure3.doCall [1]
[2]      15.6  0.00      = ;0.00      1  main.JApplication.java [2]&nbs= p;                    --------------------------------------------------------------------------= ----------

The first block of profile output is for GApplication.javaStatic, where as= the second is for JApplication.java

R,
rahul

Rahul Somasunderam
Engineer, Transcend Insigh= ts


On Jul 11, 2015, at 7:54 PM, Keegan Witt <keeganwitt@gmail.com> wrote:

Well, for one thing, Application is not completely= statically compiled.  So there is still overhead introduced that is = not present in the pure Java version.

As for your StackOverflow, I'm not really sure what to recommend, as I've = not used GProf.  I guess raising an issue on their GitHub page would = be one way of getting help from their devs.  I didn't see any mailing= lists.

-Keegan

On Sat, Jul 11, 2015 at 12:24 AM, Rahul Somasun= deram <rsomasunderam@transcendinsights.com> wrote:
Hi Keegan,

Thanks for your help. The groovy static code runs almost as fast as t= he java code when invoked from groovy code.

I went from this:

             =                   user  = ;system     cpu    real

    JApplication.java     &n= bsp;      668       0     668 &nbs= p;   668
    Application.java     &nb= sp;    365631     813  366444  371535=
    Application.javaStatic   &nbs= p;240292     405  240697  244008
    Application.groovy     &= nbsp;  787992    1005  788997  799195
    Application.groovyStatic  650= 475     985  651460  665035

to:

             =                   user  = ;system     cpu    real
    JApplication.java     &n= bsp;      718       0     718 &nbs= p;   719
    Application.java     &nb= sp;    359312     610  359922  364478=
    Application.javaStatic   &nbs= p;252557     578  253135  256752
    Application.groovy     &= nbsp;  735788     982  736770  746124
    Application.groovyStatic  341= 818     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 fas= ter 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&quo= t; java.lang.StackOverflowError
    at java.lang.Class.forName(Class.java:348)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray$1.run(Call= SiteArray.java:65)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray$1.run(Call= SiteArray.java:62)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCall= StaticSite(CallSiteArray.java:62)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCall= Site(CallSiteArray.java:159)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCal= l(CallSiteArray.java:45)
    at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call= (StaticMetaClassSite.java:55)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCal= l(CallSiteArray.java:45)
    at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call= (StaticMetaClassSite.java:55)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCal= l(CallSiteArray.java:45)
    at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call= (StaticMetaClassSite.java:55)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCal= l(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 pr= oblem 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

    &n= bsp;           &nbs= p;            user&= nbsp; system      cpu     rea= l

JApplication.java         &nb= sp;   405       0   = ;   405      431
JApplication.groovy         &= nbsp; 639       0    &nb= sp; 639      651
Application.java          108= 8350      20  1088370  1144546
Application.javaStatic     707835   &nb= sp;  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.

On Fri, Jul 10, 2015 at 5:51 PM, Keegan Witt <keeganwitt@g= mail.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 t= o be compiled statically, and the results went from

    &n= bsp;           &nbs= p;            user&= nbsp; system      cpu     rea= l

JApplication.java         &nb= sp;   433       0   = ;   433      433
JApplication.groovy         &= nbsp; 646       0    &nb= sp; 646      655
Application.java         &nbs= p; 963173   18907   982080  1131540
Application.javaStatic     750500   &nb= sp;  14   750514   853262
Application.groovy        2541527 =      41  2541568  2607827
Application.groovyStatic  2006609      30&nb= sp; 2006639  2049778

to

    &n= bsp;           &nbs= p;            user&= nbsp; system      cpu     rea= l

JApplication.java         &nb= sp;   411       0   = ;   411      411
JApplication.groovy         &= nbsp; 561       0    &nb= sp; 561      585
Application.java          102= 1404      21  1021425  1097055
Application.javaStatic     759105   &nb= sp;  15   759120   826062
Application.groovy         922849&= nbsp;     17   922866  1088130
Application.groovyStatic   762211     &= nbsp; 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 j= ust 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 Somasund= eram <rsomasunderam@transcendinsights.com> wrote:
Here's a project i've setup to run som= e 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* 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
=3D=3D=3D=3D=3D=3D=3D
* Warm Up: Auto (- 60 sec)
* CPU Time Measurement: On

             =               user  system  =   cpu    real

JApplication.java         &n= bsp;   13       0      13    =  13
JApplication.groovy         =   94       0      94     100<= /font>
Application.java         &nb= sp;426181    1584  427765  429254
Application.javaStatic    288418  = ;   918  289336  290410
Application.groovy        83= 2317    2360  834677  837481
Application.groovyStatic  687717   &nb= sp;2024  689741  697543

It looks like when Java executes the code, it's several orders of mag= nitude faster. Is there an option I can try tuning to improve groovy's odd= s 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 an= d groovy code depending on java code. Please ignore that if you want to pl= ay 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 w= hich it is addressed
and may contain CONFIDENTIAL material. If you receive this material/inform= ation in error,
please contact the sender and delete or destroy the material/information.<= br>





The information transmitted is intended only for the person or entity to w= hich it is addressed
and may contain CONFIDENTIAL material. If you receive this material/inform= ation in error,
please contact the sender and delete or destroy the material/information.<= br>



The information transmitted is intended only for the person or entity to w= hich it is addressed
and may contain CONFIDENTIAL material. If you receive this material/infor= mation in error,
please contact the sender and delete or destroy the material/information.<= BR> --_000_E7569214588C4D58946DC514D4382AB7humanacom_--