31 messages in org.codehaus.groovy.devRe: [groovy-dev] as usual on performa...
FromSent OnAttachments
Alex TkachmanFeb 27, 2008 5:38 am 
Guillaume LaforgeFeb 27, 2008 5:47 am 
Alex TkachmanFeb 27, 2008 6:01 am 
Chanwit KaewkasiFeb 27, 2008 6:21 am 
Martin C. MartinFeb 27, 2008 6:27 am 
Jochen TheodorouFeb 27, 2008 6:32 am 
Jochen TheodorouFeb 27, 2008 6:33 am 
tugwilsonFeb 27, 2008 6:55 am 
Chanwit KaewkasiFeb 27, 2008 7:15 am 
Chanwit KaewkasiFeb 27, 2008 8:01 am 
Jochen TheodorouFeb 27, 2008 8:28 am 
tugwilsonFeb 27, 2008 9:00 am 
tugwilsonFeb 27, 2008 9:55 am 
Chanwit KaewkasiFeb 27, 2008 11:27 am 
Chanwit KaewkasiFeb 27, 2008 11:31 am 
Jochen TheodorouFeb 27, 2008 11:36 am 
Alex TkachmanFeb 27, 2008 11:58 am 
Martin C. MartinFeb 27, 2008 12:18 pm 
Jochen TheodorouFeb 27, 2008 12:37 pm 
Jochen TheodorouFeb 27, 2008 12:45 pm 
tugwilsonFeb 27, 2008 12:48 pm 
tugwilsonFeb 27, 2008 12:51 pm 
Martin C. MartinFeb 27, 2008 1:27 pm 
Alex TkachmanFeb 27, 2008 1:48 pm 
tugwilsonFeb 27, 2008 2:14 pm 
Jochen TheodorouFeb 27, 2008 5:09 pm 
Alexandru Popescu ☀Feb 27, 2008 5:38 pm 
Charles Oliver NutterFeb 28, 2008 12:20 am 
Jochen TheodorouFeb 28, 2008 1:33 am 
Alexandru Popescu ☀Feb 28, 2008 2:56 am 
tugwilsonFeb 28, 2008 3:29 am 
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] as usual on performance - operations on primitivesActions...
From:Jochen Theodorou (blac@gmx.org)
Date:Feb 27, 2008 12:45:14 pm
List:org.codehaus.groovy.dev

Martin C. Martin schrieb: [...]

As soon as you call a function which accepts one of your objects as an argument, or which could somehow grab your binding and meddle with it, this optimization is no longer possible.

well, unlike Ruby you can in Groovy not change variables in the local context by for example an eval. So unless there is an assignment, which is statically known, there is no change to value. This applies even for closures.. of course they make it a bit more difficult, but not impossible I think. But you would not get much of a speed up for properties and such...

I suppose it would still be possible if you could prove that the function doesn't modify the metaclass at compile time, and note this along with the function.

ah, did mean the MetaClass... sorry. In general I can not prove that before calling the function, but I can test it after the call. For MOP 2.0 I have the vision of a constant MetaClass handle, that will not be changed and that will always point to the actual MetaClass. If this is there, then we can cache this handle, bypass the registry completely and get an easy way to check if there is a change we have to be aware of.

Then at runtime, when you resolve the call, you could see whether the invoked function could ever possibly change the metaclass.

In general.. without knowing the bytecode... I think that is really impossible ;)

bye blackdrag

-- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.com/

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

http://xircles.codehaus.org/manage_email