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 21, 2008 6:43:49 am
List:org.codehaus.groovy.dev

Tom Nichols wrote:

On Thu, Feb 21, 2008 at 8:45 AM, Martin C. Martin <mar@martincmartin.com> wrote:

when we could retool libraries that use a lot of dynamics to use less (without reducing features), etc.

I wouldn't even go there. Don't change any core libraries.

Well, I'm not talking about changing anything in Groovy distribution at all. Not even adding an annotation or a keyword. Guillaume and others have been very clear about that, and I respect that. So don't install a 3rd party patch, it won't affect you.

But I think it's an important question to ask: where can we reduce dynamism and still get all the features we know and love? Is there some other way to write the code that's about as clean, has the same features, but is a lot faster?

Do you think it's worth trying that, at least as an experiment to help drive the evolution of a FastGroovy?

Don't change anything except add an annotation (*not a keyword*) and a compiler hook (whatever way is least invasive). I personally am not looking for changes to the language per se. More like just how the bytecode is generated when the code is compiled.

There are TONS of places where any sort of "not-dynamic" semantics would mean certain core libs, and most of Grails wouldn't work inside such an annotated method i.e. map.someValue (right?) builders, slurpers, categories, obj."$method", etc. But this leaves a whole category of code that (as Martin said) is very straightforward and involves just direct method calls, arithmetic, etc. I would *love* to be able to choose "non-dynamic" Groovy syntax for my performant pieces of code rather than using Java classes. Question -- would GDK methods (like myList.each {.. } ) still work? Are they resolved into direct bytecode or do they go through the MOP?

Going through the MOP doesn't need to be a deal breaker, as long as you can interrogate the MOP at compile time and, in common cases, find out what will be called. After all, you, me and the IDEs know (or guess) what myList.each { ... } calls. We rely on that understanding when we're writing code, and if it resolved to something else, we could be quite confused. (There are many valid cases where it could resolve to something else, e.g. a "profiling MOP" that intercepts the method call to increment a counter before doing the call, or for mocking during testing, etc.)

Best, Martin

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

http://xircles.codehaus.org/manage_email