Is Groovy too slow? Certainly I found it too slow for intensive number crunching. Once I started to need multiple passes over every pixel in a 640x480 image for my image processing app things got to be too slow for my needs. That's when I had to grudgingly admit that Groovy wasn't the best tool for the job, and wrap up the logic in a Java class.
Groovy Coffe Cup - take two
-
It's been quite a while since this blog featured information on
GraphicsBuilder, I'm pleased to announce that the builder is not dead, it
actually has been...
1 day ago
2 comments:
I heard the latest beta is a good bit faster. Still may not address your specific need in this case though, which could have more to do with boxing and unboxing thousands of pixels in an image. Not sure how you rewrote this in Java, e.g. all the code, or just the specific image manipulation code. Dynamic languages on other VMs, e.g. Gambit Scheme, come with specific "built-in" data types and functions for manipulating arrays of "primitive" values, just because this kind of boxing and unboxing always interferes with big-grid-of-primitives manipulation.
That's encouraging about the beta.
I guess my post was a little irresponsible. If I wasn't so lazy I would isolate just the code in question and profile it in Groovy to see where the time was going. My guess* is that the time is going into calling the closure inside the loop over and over.
* See? I'm guessing.
Post a Comment