Kommentare zu: Poor Groovy Performance http://www.fischerlaender.net/perl/poor-groovy-performance One Blog Is Not Enough Sun, 29 Jan 2012 09:54:56 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Von: stefanie http://www.fischerlaender.net/perl/poor-groovy-performance/comment-page-1#comment-22184 stefanie Fri, 23 Jan 2009 08:36:39 +0000 http://www.fischerlaender.net/perl/poor-groovy-performance#comment-22184 groovy rocks groovy rocks

]]> Von: XiZi http://www.fischerlaender.net/perl/poor-groovy-performance/comment-page-1#comment-10268 XiZi Tue, 23 Sep 2008 12:27:50 +0000 http://www.fischerlaender.net/perl/poor-groovy-performance#comment-10268 I benchmarked compiled Groovy in an enterprise Java web application to be used as JSF backing beans and it is more than 100 times slower!!! See, so very slower than expected... I benchmarked compiled Groovy in an enterprise Java web application to be used as JSF backing beans and it is more than 100 times slower!!!
See, so very slower than expected…

]]> Von: Groovy - interesting but to slow now | Rich Internet Applications http://www.fischerlaender.net/perl/poor-groovy-performance/comment-page-1#comment-7524 Groovy - interesting but to slow now | Rich Internet Applications Wed, 11 Jun 2008 12:30:42 +0000 http://www.fischerlaender.net/perl/poor-groovy-performance#comment-7524 [...] “little” problem with Groovy - low performance You can find tests and quick comparison here. Why it is so ? explanation you can find in headius (Charles Nutter) blog in this article. [...] [...] “little” problem with Groovy – low performance You can find tests and quick comparison here. Why it is so ? explanation you can find in headius (Charles Nutter) blog in this article. [...]

]]> Von: Grant http://www.fischerlaender.net/perl/poor-groovy-performance/comment-page-1#comment-5795 Grant Fri, 14 Mar 2008 16:36:04 +0000 http://www.fischerlaender.net/perl/poor-groovy-performance#comment-5795 I know this is an old post, but it still shows up on Google, so I thought I'd post. I'm considering switching a project from Rails to Grails. After running across this post, I decided to test it out for myself. I used a sum.txt file of 1,000,000 lines (the same contents listed on the site, repeated 1,000 times). To minimize the effects of startup time, I put a for loop counting 1..10 around the whole block of code. The code I used was exactly what was posted here and on the shootout site, with the text file being read each iteration of the loop. All I've got running right now is a windows box (XP SP2, E6600 core2), so I'm not sure how to exactly measure CPU time on it. I just watched the "CPU Time" field in the task manager, and the results were: Ruby 1.8.6: 27s Ruby 1.9.0: 27s Java 1.6.0_5: 1m 6s JRuby 1.0.3: 43s JRuby 1.1 RC2: java.lang.OutOfMemoryError: Java heap space Groovy: 15s Java definitely ran the fastest once the file was loaded, but something about file IO or the StreamTokenizer class with FileInputStream really slowed it down. Loading the file into an array of 1,000,000 strings once for all 10 iterations produced: Ruby 1.8.6: 9s (179mb) Ruby 1.9.0: 9s (179mb) Java 1.6.0_5: 8s (67mb) JRuby 1.0.3: 12s (190mb) JRuby 1.1 RC2: 12s (190mb) Groovy: 13s (77mb) (ram usage in parenthesis) For the hell of it, I used Groovy code to load the file and had it pass off an ArrayList to Java to sum up, and it finished in only 2.5 seconds. I'd imagine more optimized Java would be about as quick. The difference in RAM usage seems really significant. I wonder how much RAM is used in equal size Grails vs. Rails apps? I know this is an old post, but it still shows up on Google, so I thought I’d post.

I’m considering switching a project from Rails to Grails. After running across this post, I decided to test it out for myself.

I used a sum.txt file of 1,000,000 lines (the same contents listed on the site, repeated 1,000 times). To minimize the effects of startup time, I put a for loop counting 1..10 around the whole block of code. The code I used was exactly what was posted here and on the shootout site, with the text file being read each iteration of the loop.

All I’ve got running right now is a windows box (XP SP2, E6600 core2), so I’m not sure how to exactly measure CPU time on it. I just watched the “CPU Time” field in the task manager, and the results were:

Ruby 1.8.6: 27s
Ruby 1.9.0: 27s
Java 1.6.0_5: 1m 6s
JRuby 1.0.3: 43s
JRuby 1.1 RC2: java.lang.OutOfMemoryError: Java heap space
Groovy: 15s

Java definitely ran the fastest once the file was loaded, but something about file IO or the StreamTokenizer class with FileInputStream really slowed it down.

Loading the file into an array of 1,000,000 strings once for all 10 iterations produced:
Ruby 1.8.6: 9s (179mb)
Ruby 1.9.0: 9s (179mb)
Java 1.6.0_5: 8s (67mb)
JRuby 1.0.3: 12s (190mb)
JRuby 1.1 RC2: 12s (190mb)
Groovy: 13s (77mb)
(ram usage in parenthesis)

For the hell of it, I used Groovy code to load the file and had it pass off an ArrayList to Java to sum up, and it finished in only 2.5 seconds. I’d imagine more optimized Java would be about as quick.

The difference in RAM usage seems really significant. I wonder how much RAM is used in equal size Grails vs. Rails apps?

]]> Von: Stefan http://www.fischerlaender.net/perl/poor-groovy-performance/comment-page-1#comment-2435 Stefan Sat, 15 Dec 2007 18:58:59 +0000 http://www.fischerlaender.net/perl/poor-groovy-performance#comment-2435 Thomas, how big was the file you used to calculate the sums? Wihout knowing how many times the loop had to iterate, your times don't give us much information. Thomas, how big was the file you used to calculate the sums? Wihout knowing how many times the loop had to iterate, your times don’t give us much information.

]]> Von: Thomas http://www.fischerlaender.net/perl/poor-groovy-performance/comment-page-1#comment-2428 Thomas Sat, 15 Dec 2007 10:59:59 +0000 http://www.fischerlaender.net/perl/poor-groovy-performance#comment-2428 Test 1) I added time1 and time2 and println time2-time1 lines to your test code. In groovy 1.5 command line your sum test takes 31 or *62* or 78 ms and in groovyshell 16 ms to execute. Test 2) Removing time1 and time2 code, it is taking about 30 ms by hand time measuring, by a clock, when executed from groovy command line. (My machine has 2 T7200 2 MHz processor with jdk 1.6) Test 1) I added time1 and time2 and println time2-time1 lines to your test code. In groovy 1.5 command line your sum test takes 31 or *62* or 78 ms and in groovyshell 16 ms to execute.

Test 2) Removing time1 and time2 code, it is taking about 30 ms by hand time measuring, by a clock, when executed from groovy command line.

(My machine has 2 T7200 2 MHz processor with jdk 1.6)

]]> Von: Randy http://www.fischerlaender.net/perl/poor-groovy-performance/comment-page-1#comment-2269 Randy Thu, 06 Dec 2007 11:14:33 +0000 http://www.fischerlaender.net/perl/poor-groovy-performance#comment-2269 If you want to see a very different perspective on performance this article: http://1060.org/upload/fibonacci.html examines the performance of an address space based computational environment compared to a conventional algorithmic approach. Effectively what it shows is an environment in which each computed result is located at an address (a URI address space) and each result is cached using the URI as the cache key. The net result for working systems is that computations can be done with a scripting language (JavaScript in this paper) and the whole system performs very well because redundant computations can be avoided. The system is called NetKernel which supports Groovy, JavaScript, Ruby, Python, Java and other languages. If you want to see a very different perspective on performance this article: http://1060.org/upload/fibonacci.html examines the performance of an address space based computational environment compared to a conventional algorithmic approach. Effectively what it shows is an environment in which each computed result is located at an address (a URI address space) and each result is cached using the URI as the cache key. The net result for working systems is that computations can be done with a scripting language (JavaScript in this paper) and the whole system performs very well because redundant computations can be avoided. The system is called NetKernel which supports Groovy, JavaScript, Ruby, Python, Java and other languages.

]]> Von: tom http://www.fischerlaender.net/perl/poor-groovy-performance/comment-page-1#comment-2182 tom Sun, 02 Dec 2007 08:48:54 +0000 http://www.fischerlaender.net/perl/poor-groovy-performance#comment-2182 Well, I just stumbled over a groovy book and thought: Hey, groovy has all the features I was missing in ruby and the tight java integration wouldn't be a disadvantage too. So, I ran a stupid test -- the typical prime calculation thingy. The test itself is pointless. But groovy took 12 to 15 seconds to startup, which is about the time ruby needs to finish the test. I think one of the problems lies in the startup script that scans all sorts of directories which is kind of slow with cygwin. Well, I just stumbled over a groovy book and thought: Hey, groovy has all the features I was missing in ruby and the tight java integration wouldn’t be a disadvantage too. So, I ran a stupid test — the typical prime calculation thingy. The test itself is pointless. But groovy took 12 to 15 seconds to startup, which is about the time ruby needs to finish the test. I think one of the problems lies in the startup script that scans all sorts of directories which is kind of slow with cygwin.

]]> Von: Anthony http://www.fischerlaender.net/perl/poor-groovy-performance/comment-page-1#comment-205 Anthony Fri, 17 Aug 2007 17:23:22 +0000 http://www.fischerlaender.net/perl/poor-groovy-performance#comment-205 This is not the price we pay for dynamic languages. It is noted in the benchmark that Perl was faster than Java. Lisp code can be compiled to machine language (you can have a mash of interpreted and compiled functions), and good Lisp code will in general be less than 2x more expensive than C (ike Java) In conclusion, Groovy's performance (or lack thereof) cannot be attributed to an intrinsic feature of dynamic languages. This is not the price we pay for dynamic languages.
It is noted in the benchmark that Perl was faster than Java. Lisp code can be compiled to machine language (you can have a mash of interpreted and compiled functions), and good Lisp code will in general be less than 2x more expensive than C (ike Java)
In conclusion, Groovy’s performance (or lack thereof) cannot be attributed to an intrinsic feature of dynamic languages.

]]> Von: Stefan http://www.fischerlaender.net/perl/poor-groovy-performance/comment-page-1#comment-175 Stefan Wed, 08 Aug 2007 08:22:43 +0000 http://www.fischerlaender.net/perl/poor-groovy-performance#comment-175 Jason, I'm not disappointed that Groovy is slower than Java. This is the price we pay for dynamic languages, because it makes live easier for us programmers. I'm disappointed that Groovy is that much slower than Perl, Ruby and even PHP - all of them also dynamic languages with a start-up penalty. I did this benchmarks prior to a decision to what technology to use for a new project. This project involves a lot of processing in the back-end, so runtime performance is important. And we wanted to use the same language for the front-end, too, for obvious reasons. Of course we could have used Groovy for the front-end and Java for the heavy back-end work, but we wanted a dynamic(!) language for the back-end. Jason,
I’m not disappointed that Groovy is slower than Java. This is the price we pay for dynamic languages, because it makes live easier for us programmers. I’m disappointed that Groovy is that much slower than Perl, Ruby and even PHP – all of them also dynamic languages with a start-up penalty.
I did this benchmarks prior to a decision to what technology to use for a new project. This project involves a lot of processing in the back-end, so runtime performance is important. And we wanted to use the same language for the front-end, too, for obvious reasons. Of course we could have used Groovy for the front-end and Java for the heavy back-end work, but we wanted a dynamic(!) language for the back-end.

]]>