62 messages in org.codehaus.groovy.devRe: [groovy-dev] Groovy performance: ...
FromSent OnAttachments
Alex TkachmanFeb 19, 2008 2:09 am 
Steven DevijverFeb 19, 2008 2:37 am 
Alexandru Popescu ☀Feb 19, 2008 2:57 am 
Alex TkachmanFeb 19, 2008 3:03 am 
Patric BechtelFeb 19, 2008 3:12 am 
Guillaume LaforgeFeb 19, 2008 3:25 am 
Guillaume LaforgeFeb 19, 2008 3:26 am 
Patric BechtelFeb 19, 2008 5:05 am 
Gavin GroverFeb 19, 2008 5:51 am 
Steven DevijverFeb 19, 2008 5:52 am 
Guillaume LaforgeFeb 19, 2008 5:54 am 
Tom NicholsFeb 19, 2008 6:26 am 
Alex TkachmanFeb 19, 2008 6:28 am 
Guillaume LaforgeFeb 19, 2008 6:35 am 
Tom NicholsFeb 19, 2008 7:03 am 
Guillaume LaforgeFeb 19, 2008 7:38 am 
Chanwit KaewkasiFeb 19, 2008 7:52 am 
Charles Oliver NutterFeb 19, 2008 8:49 am 
Steven DevijverFeb 19, 2008 10:03 am 
Charles Oliver NutterFeb 19, 2008 11:38 am 
Steven DevijverFeb 19, 2008 12:11 pm 
Alex TkachmanFeb 19, 2008 12:39 pm 
Alex TkachmanFeb 19, 2008 12:48 pm 
tugwilsonFeb 19, 2008 1:36 pm 
Alex TkachmanFeb 19, 2008 8:51 pm 
Guillaume LaforgeFeb 20, 2008 2:10 am 
Jochen TheodorouFeb 20, 2008 9:46 am 
Martin C. MartinFeb 20, 2008 5:25 pm 
Guillaume LaforgeFeb 21, 2008 1:35 am 
Tom NicholsFeb 21, 2008 4:15 am 
Martin C. MartinFeb 21, 2008 5:44 am 
Tom NicholsFeb 21, 2008 6:22 am 
Smith, Jason, CTR, OASD(HA)/TMAFeb 21, 2008 6:34 am 
Martin C. MartinFeb 21, 2008 6:43 am 
Guillaume LaforgeFeb 21, 2008 6:48 am 
Guillaume LaforgeFeb 21, 2008 7:04 am 
Smith, Jason, CTR, OASD(HA)/TMAFeb 21, 2008 7:18 am 
Charles Oliver NutterFeb 21, 2008 7:38 am 
Guillaume LaforgeFeb 21, 2008 7:42 am 
Martin C. MartinFeb 21, 2008 8:36 am 
Martin C. MartinFeb 21, 2008 8:48 am 
Pascal DeMillyFeb 21, 2008 5:35 pm 
Gavin GroverFeb 21, 2008 6:21 pm 
Jochen TheodorouFeb 22, 2008 4:31 am 
Tom NicholsFeb 22, 2008 4:49 am 
Charles Oliver NutterFeb 22, 2008 11:43 pm 
Guillaume LaforgeFeb 23, 2008 12:28 am 
Martin C. MartinFeb 23, 2008 3:51 am 
Jochen TheodorouFeb 23, 2008 2:49 pm 
Jochen TheodorouFeb 23, 2008 2:53 pm 
Charles Oliver NutterFeb 24, 2008 2:01 am 
Martin C. MartinFeb 24, 2008 3:56 am 
Martin C. MartinFeb 24, 2008 4:11 am 
Charles Oliver NutterFeb 24, 2008 5:12 am 
Jochen TheodorouFeb 24, 2008 3:17 pm 
Jochen TheodorouFeb 24, 2008 3:31 pm 
Alexandru Popescu ☀Feb 24, 2008 3:36 pm 
Martin C. MartinFeb 26, 2008 2:20 pm 
Martin C. MartinFeb 26, 2008 3:15 pm 
Jochen TheodorouFeb 27, 2008 2:38 am 
Jochen TheodorouFeb 27, 2008 3:03 am 
Martin C. MartinMar 2, 2008 5:21 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [groovy-dev] Groovy performance: what to doActions...
From:Martin C. Martin (mar@martincmartin.com)
Date:Feb 20, 2008 5:25:38 pm
List:org.codehaus.groovy.dev

Guillaume Laforge wrote:

However, as this has been discussed on this list a few times already or at the last Groovy Developer Conference, it's better and saner to make Groovy the fastest dynamic language possible on the JVM by creating the best second generation MOP, rather than by adding a few hacks to make Groovy a more statically typed language.

What would happen if such a proposal was committed? In a few months from now, all Groovy code samples we would come across would be littered with @Typed annotations all around -- who remembers the ugly @Property annotation making your Groovy beans ugly?

True, although it could be changed to a keyword. "static" is already taken in Java (and C and C++) to mean something else, but we could think of another keyword, e.g. "typed."

A few months later, and people will wonder why this is not the default behavior and be applied to all possible methods or classes. Groovy will become more and more statically typed, and for "performance sake", we'd imagine other such hacks to make Groovy less and less dynamic over time, or littered with ugly annotations.

I'm surprised you're so sure how people would use this particular feature. I work with the one language I know of that has optional typing for efficiency: Lisp. In our code base, it's not used too much, because (a) most people worry about getting the job done, and only focus on performance when it becomes a problem, and (b) it tends to clutter up the code, and people don't want to clutter up the code for no good reason. It seems a strong possibility that this would turns out the same way in Groovy. However, it's also possible things will turn out the way you say.

But, I'm not sure it's such a bad thing. People tend to assume things are static, and are surprised by the (possibility of) the dynamic nature. For example, people are often surprised that mylist.size() can't be compiled to mylist.length. They're even more surprised that when used in a loop, that it isn't resolved just the first time through but every time through.

Such a proposal would be a consent that we failed to make Groovy the fastest dynamic language possible. Have we really tried to make Groovy as fast as possible? Have we implemented a second generation MOP yet? No.

I'm worried that this will end up turning into a Sufficiently Smart Compiler, something that's so hard to do right that it never happens:

http://c2.com/cgi/wiki?SufficientlySmartCompiler

Furthermore, even with such an annotation, this code path would always be slower than raw Java anyway.

True, but it would often be "fast enough." If Groovy is, say, 10 to 20 times slower than Java, and by sprinkling a few keywords or annotations around you can get it 2 times slower, that will often be good enough, and there'll be no reason to rewrite it in Java.

Remember that Groovy has not been conceived to replace Java, but as a complement, an adjunct, an enhancer to Java. It's a core value of the language and the project. With the joint compiler, the ant tasks, the maven plugin, it's so easy to just implement one additional Java class, that it is totally seamless and transparent to mix Groovy and Java together.

When raw performance matter, using Java is simply the best option, and nothing we could do would make the code faster than raw Java.

Actually, that's not true. The main product of the company I work for is a search engine for air fares. It's used by some of the main travel sites in the U.S. (Orbitz.com and Kayak.com), and by most big U.S. airlines. It's very performance intensive code; whenever you do a search, it takes many seconds to find the answer, and that's one of the biggest complaints. Yet it's not written in C/C++ or any other statically typed language. It's written in Lisp.

Why? Because its complex algorithmic code, and it would be several times longer in a statically typed language. It would be even harder to understand. There's no single bottleneck, there are around 20 stages, and depending on the query each of them can take a significant amount of time.

So, I think it's a shame that Groovy can't replace Java, and I really don't see why it couldn't.

It doesn't mean that Groovy can't be made more performant than it is today, on the contrary, it's time to work on MOP2 instead. So you can focus your energy on something less frustrating if you so wish.

As discussed several times already, we should focus now on this new Meta-Object Protocol, perhaps to make Groovy even more dynamic, but to make it the faster possible dynamic language across all possible platforms -- it's not an unrealistic goal to be faster than Ruby and Python.

Faster than Ruby and Python is realistic without compiler hints, but it seems that significantly faster than that is relatively easy to do.

I wonder: how often are the more extreme dynamic aspects of Groovy, or any dynamic language, actually used? How often is a meta object protocol (other than default ones) actually used? How often are per-instance MOPs used? How often are the changed at runtime?

--------------------------------------------------------------------- To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email