Measuring IronPython Performance Part III
Dave Fugate has written part 3 of his guide to measuring IronPython performance. In this entry he discusses things that can affect performance - not just different versions of .NET, but even security patches (!) can make a difference.
Interestingly, due to practical limitations, the dynamic languages team only test on various configurations of Vista. This is despite the fact that, however much Microsoft wishes otherwise, most of their customers are still going to be using it with Windows XP...
Vista comes with .NET 3 as standard - but IronPython itself only depends on .NET 2 (with Visual Studio 2008 you can set the version of .NET you are targeting when you compile). Specifically, IronPython 2 depends on .NET 2 SP1,which is actually more recent than .NET 3 - Service Pack 1 came out in November 2007.
At Resolver Systems we are selling Resolver One into financial organisations, some of whom are technologically conservative, so it is possible that the requirement for .NET 2.0 SP1 will affect our ability to move to IronPython 2. As IronPython 2 is still in beta it is something we haven't yet evaluated (although we have ported Resolver One to IronPython 2 to test there would be no major problems when we do make the change).
On the other hand, the .NET 2 service pack did fix some bugs on the Common Language Runtime (which is why IronPython depends on it). For example, it means that running IronPython code in an AppDomain with reduced privileges now works.
From the article:
As a concrete example, the following measurements were taken from a single 32-bit Vista machine under .NET 3.5 and .NET 3.5 SP1:
The moral of this story is to always include every machine setup detail you can think of when reporting performance results. Some things you might not expect to impact performance actually do.
Interestingly, due to practical limitations, the dynamic languages team only test on various configurations of Vista. This is despite the fact that, however much Microsoft wishes otherwise, most of their customers are still going to be using it with Windows XP...
Vista comes with .NET 3 as standard - but IronPython itself only depends on .NET 2 (with Visual Studio 2008 you can set the version of .NET you are targeting when you compile). Specifically, IronPython 2 depends on .NET 2 SP1,which is actually more recent than .NET 3 - Service Pack 1 came out in November 2007.
At Resolver Systems we are selling Resolver One into financial organisations, some of whom are technologically conservative, so it is possible that the requirement for .NET 2.0 SP1 will affect our ability to move to IronPython 2. As IronPython 2 is still in beta it is something we haven't yet evaluated (although we have ported Resolver One to IronPython 2 to test there would be no major problems when we do make the change).
On the other hand, the .NET 2 service pack did fix some bugs on the Common Language Runtime (which is why IronPython depends on it). For example, it means that running IronPython code in an AppDomain with reduced privileges now works.
From the article:
As a concrete example, the following measurements were taken from a single 32-bit Vista machine under .NET 3.5 and .NET 3.5 SP1:
- float comparisons were 37% faster under .NET 3.5 SP1
- nested for loops were 30% faster under .NET 3.5 SP1
- method invocations slowed down 26% under .NET 3.5 SP1
The moral of this story is to always include every machine setup detail you can think of when reporting performance results. Some things you might not expect to impact performance actually do.
Comments
Post a Comment