[IronPython] Issues with the OptimizedFunctionAny

Dino Viehland dinov at exchange.microsoft.com
Sun Apr 2 22:32:51 CEST 2006


The real fix is to add this function to BuiltinFunction.Generated.cs in OptimizedFunctionAny:

public override object Call(ICallerContext context, params object[] args) {
    if (IsContextAware) {
        object[] newArgs = new object[args.Length + 1];
        newArgs[0] = context;
        Array.Copy(args, 0, newArgs, 1, args.Length);
        return Call(newArgs);
    }
    return Call(args);
}

The optimizer is actually doing its job - infact the first call goes through the optimized path, but it comes at it from a slightly different direction.

The problem is that in beta 5 we made functions that take context (hasattr, getattr, setattr are the big ones here) could also be optimized.  But we apparently missed the large of # arguments case.

Thanks for the bug report, hopefully this will unblock you, and we'll get it fixed in beta 6.


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Sunday, April 02, 2006 1:16 PM
To: Discussion of IronPython; IronPython List
Subject: Re: [IronPython] Issues with the OptimizedFunctionAny

At the console there's an easy workaround:

>>> zip = zip
>>> p = ((1,2),)
>>> zip(*(p*10))
[(1, 1, 1, 1, 1, 1, 1, 1, 1, 1), (2, 2, 2, 2, 2, 2, 2, 2, 2, 2)]
>>> zip(*(p*10))
[(1, 1, 1, 1, 1, 1, 1, 1, 1, 1), (2, 2, 2, 2, 2, 2, 2, 2, 2, 2)]

Unfortunately that doesn't help you in a module where we'll always optimize the method.

Another work around that involves changing the source code is updating CanOptimize(MethodBase mi) in IronPython\Compiler\ReflectOptimizer.cs.

You can just add something like:

if(mi.Name == "zip") return false;

and it'll suppress the optimization of that method.

We should actually be able to handle more than 5 arguments in this case (via a params arg) so hopefully it's just a simple bug, but I'll have to look into it.

The optimization it's self is switching from a late-bound method invocation via reflection to an optimized caller stub.  The 5 args limit is for non-params args (it's tricky because we get into having mixed # of arguments in the same method).


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Jacobs
Sent: Sunday, April 02, 2006 1:06 AM
To: IronPython List
Subject: [IronPython] Issues with the OptimizedFunctionAny

Hi,

I've stumbled across this interesting behaviour:

 >>> p = ((1, 2),)
 >>> zip(*(p * 10))
[(1, 1, 1, 1, 1, 1, 1, 1, 1, 1), (2, 2, 2, 2, 2, 2, 2, 2, 2, 2)]
 >>> zip(*(p * 10))
Traceback (most recent call last):
   File , line 0, in input##10
TypeError: zip() takes at most 0 arguments (10 given)

Upon the first-time calling the method it is a "ReflectedMethod" object, this
is then optimized (compiled?) to an "OptimizedFunctionAny" object somewhere
along the line, which appears to have problems accepting more than 5
parameters (according to the source code, anyway.)

This seems like a pretty serious issue. Is there any way I can get around it
in the meanwhile?

Regards
--
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



More information about the Ironpython-users mailing list