Performance of IronPython vs. C#

The Loose XAML blog has posted an interesting article profiling some IronPython code and the semantically identical C# and C code (for generating the fibonnaci series). He comes to the unsurprising conclusion that C# is substantially faster, but digs deeper into the results to try and work out why. An interesting discussion ensues in the comments.

• Performance of IronPython vs. C#

 I’ve been using IronPython for a while, and every now and then I do a cursory check to see how it’s performs against the equivalent C# code. C# is generally a touch faster at most logic, but IronPython is faster at dynamic invocation of methods than reflection in C#. In general it’s a wash…over the course of an application you dabble in things that different languages are better optimized to handle. When performance is a wash, you get the freedom to choose entirely based on the features of each language, which is nice.

This was going well, until I had a need to do some recursion. I found that the recursive IronPython code was executing extremely slowly – code that was taking milliseconds in C# was taking minutes in IronPython. That’s not a wash anymore…it’s a few orders of magnitude. So to really figure out what’s going on with these recursive calls, I made two implementations of calculating Fibonacci numbers – one in C# and one in IronPython.

Of course performance is one of the tradeoffs you make when choosing between a dynamically typed language and a statically typed one. If your application is not computationally bound, but is network, database or I/O bound then the performance of your programming language *may* be more-or-less irrelevant. On the other hand, if a 'slower' language is more flexible and expressive, or you can develop faster with it, then you may be able to spend more time optimising your algorithms and still have acceptable performance.

This has been my practical experience at Resolver Systems where we have always been open to the idea of moving core parts of the application into C# but have basically always been able to gain our targetted performance improvements by refactoring and optimising without having to rewrite in another language. With the extra code rewriting in C# would require (and studies show that bugs are pretty much proportional to lines of code irrespective of the language you use), and how much extra work C# is to test than Python,  keeping as much code as possible in Python is something that the development team appreciates.