Pain and Glory from the Trenches of the IT World

Every so often we hear of technologies being brought together in a way that will mean nothing but performance trouble. After reading an article about IronMonkey, I think we might just be witnessing such a situation.

The article describes the goal of the IronMonkey project as this: IronMonkey is setting out with the goal of mapping Microsoft’s Common Intermediate Language (CIL) to ActionScript Byte Code (ABC), allowing additional language implementations, such as IronPython and IronRuby, to run in the Tamarin Virtual Machine.

In terms of performance, I see no good coming out of this. Just consider what they’re combining. They’re taking Python and Ruby implementations that run on .NET, and moving them to run on the browser-based Tamarin virtual machine. Although they are excellent languages and offer a high degree of developer productivity, Python and Ruby aren’t known for their speed. This is true for the C-based implementations, and I imagine their performance is even worse with the implementations running on .NET. So at the highest level, we’re running into very serious performance-related issues.

At a lower level, we’re now dealing with a virtual machine embedded in a Web browser. Although Adobe and Mozilla are putting a lot of effort and resources towards Tamarin, I can’t help but wonder how poorly it will perform. The past JavaScript implementations have never performed very well, so it’s quite possible that the future implementations will suffer from performance issues, too. And although it is often claimed that bytecode virtual machines can offer performance improvements by allowing processor-specific optimizations to take place at runtime, I have to say this typically isn’t the case.

Performance often starts to suffer when you run a program using an interpreter which itself is running on a bytecode virtual machine. In terms of CPU usage, a lot of extra work is being performed for each statement or expression of the program being run in the highest-level interpreter. Beyond that, there is additional memory overhead for the interpreter and the bytecode VM, along with any additional supporting code at all levels. Many times the CPU cache just isn’t used effectively by such a code stack. Those are all key factors leading to poor performance.

I’m actually glad we’re seeing this sort of a project go forward. Perhaps before we return to our sensibilities, we need to see a very evident failure. In terms of performance, I think this effort may just lead to such a disaster.

This entry was posted on Thursday, August 9th, 2007 at 3:08 am and is filed under Development, Firefox, Open Source, Python, Ruby, Software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.