一直以来对CLR即时编译生成的汇编码抱有很多疑问，很多地方并没有像微软声称的那样被优化，尤其是并没有内联(inline)。曾经猜想那是为了IDE能够调试而少做了一些优化，在不连接调试器的情况下应该能声称最优代码。随着.NET 3.5 SP1的发布，谜团终于解开了。
.NET 2.0的CLR并没有对含有值类型(value type)参数、返回值或局部变量的函数做内联。当然，这也包括所有值类型的属性getter和setter。这是多么令人心痛的性能损失啊！值类型本来是设计成轻量级以提高性能的，结果却在优化方面大打折扣，反而不如引用类型。3.5 SP1终于补救了这一点，虽然太晚了一点，但聊胜于无。
这样C#和C++的性能争论（有争论的必要吗？）完全可以画个句号了：在.NET 3.5 SP1之前，相同的算法必定是C++快。那些对CLR即时编译能对当前CPU架构做特别优化而提高性能的期望可以完全忽略了。
补救虽然来得晚了，但也带来了另外一份礼物：值类型局部变量将能被优化成寄存器变量了。这是个C/C++里尽人皆知却极少被真正实现的优化。直到C语言的C99规范引入了__restrict修饰符，才使这种优化彻底成为可能。而C++目前还只能望洋兴叹，或者等待C++ 0x规范也加入__restrict。而新的.NET CLR将能在即时编译的条件下找出能够晋级到寄存器的变量，而不必再访问堆栈，从而大幅提高性能。
参考链接：
http://blogs.msdn.com/clrcodegeneration/archive/2007/11/02/how-are-value-types-implemented-in-the-32-bit-clr-what-has-been-done-to-improve-their-performance.aspx
发表于 @ 2008年08月22日 15:02:00|评论(loading...)|收藏