Re: Timings for the new version of Closure

On 18 May 2004, at 14:21, John Wilson wrote:
> On 18 May 2004, at 13:30, jastrachan@... wrote:
>
>> Who-hoo! Great work John! I like nicer numbers :)
>>
>>
>
> :)
>
> I think we can improve the performance within the closure now:
>
> Access to methods and properties on the enclosing class are slowed by 
> the fact that they are first dynamically resolved against the Closure 
> instance. Only if that resolution fails is the enclosing class tried.
>
> Resolving everything against the Closure instance is not nice. It 
> exposes the implementation details of Closure to the outside world. I 
> think that only the properties "delegate" and "owner" should be 
> exposed. I would propose that no method is dynamically resolved 
> against the Closure instance and that only these two properties should 
> be exposed. It would make the whole thing cleaner irrespective of the 
> performance improvement.

Agreed.

Also we can be far more efficient at choosing which one to dispatch to 
than doing a try/catch. I was wondering if we could have some special 
API like

MetaMethod method = delegate.findMethod(arguments);
if ( method == null) {
     method = owner.findMethod(arguments);
     if (method == null) { // barf!
     }
}
method.invoke(arguments);

to avoid the try/catch stuff. Also we can probably optimise the 
findMethod() implementation somewhat.

I wonder if we could statically figure out what are calls to the 
delegate & what are to the owner, but I suspect not.

> However I'm pretty ignorant of the way in which reference to on stack 
> data outside the closure is handled:
>
> m(a) {
> 	{ |x| a + x }
> }
>
> There must be some funky stuff done to make a persist when m returns. 
> Are there extra fields/methods generated on the Closure subclass? If 
> so it makes things slightly more interesting ;)

Yes - shared values are stored as fields; though I don't think their 
resolution goes throw get/setProperty / invokeMethod(). The bytecode in 
the doCall() method uses them directly..

James
-------
http://radio.weblogs.com/0112098/