Dave Fugate on IronPython Details
Dave Fugate is an IronPython tester, and often responsible for releases. He's posted a few blog entries on recent changes in IronPython 2.6 (alpha 1 was just released) and building IronPython from source for Silverlight.
In Python 2.6 the standard library collections module uses sys._getframe, which doesn't work for frame depths greater than 0 in the current IronPython. A whole host of other standard library modules depend on collections, meaning that they are all currently broken for IronPython 2.6! Dave explains how to modify collections.py to get round the problem. The good news is that in the final version of IronPython 2.6 getframe will be available from a command line switch (there is a performance hit for having it enabled). Without the switch it will be undefined (and collections.py already has a workaround for this), so that in either case you will be able to use an unmodified standard library.
Not as easy as you might expect it turns out... Dave tells us the magic incantations required to build source releases of IronPython and IronRuby for use with the Silverlight browser plugin. Writing Python code that runs in the browser is great fun by the way.
One of the big changes in IronPython 2.6 is the use of adaptive compilation for performance reasons. Compiling Python source code to IL bytecode is expensive (but has performance benefits itself) and if you only execute code once then it isn't worth the overhead. With adaptive compilation, running Python code from source with IronPython doesn't compile by default, but compiles code in the background that you execute more than once. This improves both startup and execution time for scripts or infrequently executed code. If you are compiling your code and doing a binary distribution this change doesn't affect you.
As adaptive compilation is a work in progress you may currently see a performance regression with IronPython 2.6. Using the -O command line option switches IronPython back to compiling everything (the 2.0 behaviour).
In Python 2.6 the standard library collections module uses sys._getframe, which doesn't work for frame depths greater than 0 in the current IronPython. A whole host of other standard library modules depend on collections, meaning that they are all currently broken for IronPython 2.6! Dave explains how to modify collections.py to get round the problem. The good news is that in the final version of IronPython 2.6 getframe will be available from a command line switch (there is a performance hit for having it enabled). Without the switch it will be undefined (and collections.py already has a workaround for this), so that in either case you will be able to use an unmodified standard library.
Not as easy as you might expect it turns out... Dave tells us the magic incantations required to build source releases of IronPython and IronRuby for use with the Silverlight browser plugin. Writing Python code that runs in the browser is great fun by the way.
One of the big changes in IronPython 2.6 is the use of adaptive compilation for performance reasons. Compiling Python source code to IL bytecode is expensive (but has performance benefits itself) and if you only execute code once then it isn't worth the overhead. With adaptive compilation, running Python code from source with IronPython doesn't compile by default, but compiles code in the background that you execute more than once. This improves both startup and execution time for scripts or infrequently executed code. If you are compiling your code and doing a binary distribution this change doesn't affect you.
As adaptive compilation is a work in progress you may currently see a performance regression with IronPython 2.6. Using the -O command line option switches IronPython back to compiling everything (the 2.0 behaviour).
Comments
Post a Comment