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 23, 2008 3:51:49 am
List:org.codehaus.groovy.dev

Charles Oliver Nutter wrote:

Excellent summary of the problems with this proposal. I have some comments below.

Jochen Theodorou wrote:

Groovy has atm dynamic typing. Any change with a fast mode goals a more or less static system, which is a major change for such a language. There is either version 2, which will mean you can not mix dynamic typed parts and static typed parts in the same area and there is version 3 which allows that, but will also give not many hints when it will do static and when it will do dynamic typing.

This is exactly what worried me. Because static typing goes through an entirely different mechanism, it would be both confusing and problematic for users. This is further complicated by the many users that would try to take their Groovy code and "make it faster" by adding static types. Suddenly dispatch rules would be completely different, and the code would break.

What do you think of the proposal that is simply a hint? The one where you tell the compiler you expect given object classes and metaclasses? There are two ways it could go:

- At runtime, if we don't have the expected classes & metaclasses, ignore the hint and do what you would have done anyway. This way, the semantics aren't changed, but if the types are as expected the call is much faster. If not, it's a little slower.

- At runtime, if things don't match, signal an error. This turns it into an assertion mechanism. This might be helpful in tracking down bugs and making the programmer's intention clearer, as well as performance.

??

Best, Martin

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

http://xircles.codehaus.org/manage_email