ah there you go. Cedric's the man. Owen Rubel 415-971-0976 [email protected]
On Mon, May 11, 2015 at 9:12 AM, Cédric Champeau <[email protected]> wrote: > The title of the post is misleading. Guillaume never said that Groovy was > faster than Java. It's not. At best it can be as fast as Java, and in some > very particular situations faster (in some microbenchmarks), but it's a > side effect of JIT'ing. I would certainly not say that Groovy is faster. > > 2015-05-11 18:07 GMT+02:00 Owen Rubel <[email protected]>: > >> Well in the past, Groovy has been shown to be faster than Java at times >> mainly because of it's compiler. So this is why I interpreted it this way >> and why it may or may not be the case. And again why I would love to see >> some stats on this. >> >> I mean we ALL know its faster for development, easier to learn, >> convention over config... but now faster than Java??? That is just the >> icing on the cake >> >> Owen Rubel >> 415-971-0976 >> [email protected] >> >> On Mon, May 11, 2015 at 8:25 AM, Winnebeck, Jason < >> [email protected]> wrote: >> >>> I didn’t get that when I saw it. It’s a pretty major statement to make >>> without anything behind it. The blog post references a video interview of >>> Guillaume at devoxx, and I thought I only heard him say that the static >>> compilation mode just makes it “as fast as Java” (which seems to be >>> approximately true, except that the static mode I think still injects some >>> Groovy-specific code normally not found in Java). But, the weekly post is >>> on Guillaume’s blog so why would he mis-quote himself? >>> >>> >>> >>> If it is true that Groovy is faster than Java anywhere I would be very >>> interested in seeing these results or benchmarks as well. >>> >>> >>> >>> Diverging only slightly, I don’t see how Groovy can beat Java in a >>> general sense given that Groovy generates bytecode and Java and JVM are >>> tuned to each other given Java is primary use case of bytecode and JVM, and >>> also Groovy even in static compile mode can still do more work than Java >>> (think like asType call for “casting”, and closures do have non-zero >>> overhead compared to loop). However, I can see some potential wins against >>> Java in the area of AST transformation where one could use AST >>> transformation to do at compile time things one might do at Java runtime >>> via reflection or aspects/proxies (example, commons-lang’s HashCodeBuilder >>> using reflection versus EqualsAndHashCode AST), and for configuration which >>> are compiled and run rather than “interpreting” XML or similar files. >>> >>> >>> >>> Jason >>> >>> >>> >>> *From:* Owen Rubel [mailto:[email protected]] >>> *Sent:* Monday, May 11, 2015 10:34 AM >>> *To:* [email protected] >>> *Subject:* Re: [ANN] Groovy Weekly #68 >>> >>> >>> >>> Groovy now faster than Java on Android???! I want to shout this from the >>> four corners of the earth! Are there benchmarks? >>> >>> >>> Owen Rubel >>> 415-971-0976 >>> [email protected] >>> >>> >>> >>> On Tue, Apr 28, 2015 at 12:23 AM, Guillaume Laforge <[email protected]> >>> wrote: >>> >>> Hi all, >>> >>> >>> >>> Another Tuesday, another Groovy Weekly edition! >>> >>> http://glaforge.appspot.com/article/groovy-weekly-68 >>> >>> >>> >>> Please don't forget to *subscribe to the new mailing-lists >>> <http://www.groovy-lang.org/mailing-lists.html> at Apache*, as the user >>> / dev ones at Codehaus will be decommissioned in about two weeks. Also note >>> the new address of JIRA and Git. >>> >>> >>> >>> Keep on groovy-ing !!! >>> >>> >>> >>> -- >>> >>> Guillaume Laforge >>> Groovy Project Manager >>> >>> Product Ninja & Advocate at Restlet <http://restlet.com> >>> >>> >>> >>> Blog: http://glaforge.appspot.com/ >>> >>> Social: @glaforge <http://twitter.com/glaforge> / Google+ >>> <https://plus.google.com/u/0/114130972232398734985/posts> >>> >>> >>> ------------------------------ >>> This email message and any attachments are for the sole use of the >>> intended recipient(s). Any unauthorized review, use, disclosure or >>> distribution is prohibited. If you are not the intended recipient, please >>> contact the sender by reply email and destroy all copies of the original >>> message and any attachments. >>> >> >> >
