Cook Computing


July 29, 2004 Written by Charles Cook

Jim Hugenin has released IronPython 0.6. Also. Jason Zander, CLR Product Unit Manager, has announced that Jim is joining the CLR team. Taken from the distribution this is a sample WinForms app:

from System.Windows.Forms import *
from System.Drawing import *

f = Form(Text="Windows fun with IronPython", HelpButton=True,
         MinimizeBox=False, MaximizeBox=False)

f.FormBorderStyle = FormBorderStyle.FixedDialog
f.StartPosition = FormStartPosition.CenterScreen

b1 = Button(Text="Say Something", Location=Point(30,30), Size=Size(100,30))

def push(data, event):
    l = Label(Text="IronPython Is Alive!", ForeColor=Color.Red)
    l.Location = Point(30, 50+f.Controls.Count*25)

b1.Click += push


Performance is a key issue here and I wrote some simple code to get a very unscientific rough feel for what IronPython can achieve. The following code running in IronPython does about 1,000,000 calls to Add per second:

class Adder:
    def Add(self, x, y):
        return x + y

z = 0
adder = Adder()
for i in range(10000000):
    z = adder.Add(z, 1)
print z

whereas the following C# code does about 30,000,000 calls per second (deriving from MarshalByRefObject to prevent inlining of the call - its 20 times faster when inlined):

class Adder : System.MarshalByRefObject
    int Add(int x, int y)
            return x + y;

    public static void Main()
        Adder adder = new Adder();
        int z = 0;
        for (int i = 0; i < 100000000; i++)
            z = adder.Add(z, 1);

This order of performance difference doesn't seem too bad to me if you want the benefits of coding in Python, and you can always re-implement performance critical code in C# later on. Optional typing and type inference might be another way of approaching optimization but I don't know if there are any plans for that in Python.

I'm looking forward to seeing the slides for Jim's talk at OSCON last night and the blogging about it.