几种典型的错误的性能论调或方法
1. 函数计时论
要比较性能吗?那好我们写一段函数，用一个时间计数器，在函数执行开始处记录下时间，在函数执行结束前记录下时间，最后一减得到的时间差，同样的功能，哪个语言(或者哪种方式)用的时间少，哪个语言(或者哪个方式)用的时间多，性能差别，一目了然。多客观啊!!!
比如，老赵曾经在这篇博文中：一个简单的性能计数器：CodeTimer http://www.cnblogs.com/jeffreyzhao/archive/2009/03/10/codetimer.html 抄袭.NET技术大会上Jeffrey Richter老人家show的性能计数器。
然后下面这两篇文章都是用这种“函数计时论”：
《C# vs C++ 全局照明渲染性能比试》: http://www.cnblogs.com/miloyip/archive/2010/06/23/cpp_vs_cs_GI.html
《回firelong之C#慢》 http://www.cnblogs.com/sumtec/archive/2010/06/22/1762564.html
问题是这种做法真的全面、客观的反映了编程语言的性能了吗???用这种办法你可以说某一段C#代码性能还凑合(比如《C# vs C++ 全局照明渲染性能比试》一文中的实验结果，比C/C++差也就20~30%嘛，差的不多嘛!)，但是问题是，这就是它们性能差别的全部真相吗?
函数记时论，测量的只是某一个微观代码段的性能。不是一个软件的总体性能。比如“函数记时论”就常常忽略掉我们前面metadata所带来的高额的“空间成本”和“时间成本”。正规公司，只要是care性能的，对于性能评测都有一个系统的、全面的、完整的过程(比如在我们公司称作Performance Process，和单元测试、重构、等都作为一个严肃的软件开发过程中的一个环节而存在)，会借助一些系统性的工具：比如Compuware的Application Performance Management Solutions：参见这里：http://www.compuware.com/solutions/application-performance-management.asp来做一些系统性的评测报告。不是拿个CodeTimer这样的玩具输出几个时间值，就拍脑袋下结论的。
函数计时论经常在各种技术社区中，吵架时展示的tricky demo中用于比较性能，但是放到一个正规公司的严肃项目里面，绝对不会使用这种方法来评估一个编程语言，平台，或者软件的性能。
我希望 “老赵们”以后不要再拿CodeTimer这种玩具说事，要真全面比较性能，用Compuware的Application Performance Management Solutions一整套工具和过程来比较整个软件的性能，而不是某一段微观代码的性能。
2. 性能选择论
某个功能影响性能，你不用不就没影响了吗?又没有人逼你用!
前面已经证明，C#/.NET的反射功能，你哪怕一点也不用，也有很大的性能成本(即：代码中完全不用反射，为了支持反射的metadata带来的空间成本和时间成本也非常高昂)。所以希望以后“老赵们”不要再说这样的话。
3. 损失忽视论
这个功能带来的性能损失是很小的，可以忽略不计。
性能是一个软件最核心的使用指标——如果一个软件性能不行，就是差软件!没有哪些个性能损失是可以忽略不计的。因为在程序代码中，任何一个性能损失点，都有可能因为各种因素被放大(比如长循环，大规模并发用户等)。
“老赵们”喜欢写“性能不咋地的高级企业应用”，然后忽悠客户加硬件。但是请不要忽悠整个.NET社区的程序员以为天下的软件都是“很高级的企业应用”。
4. 性能垫背论
“Java的这个feature性能比C#的差，所以C#这个feature性能好”——C#的某些feature(比如反射)性能比Java好，但并不能说明这个feature本身没有性能问题(这只能说明Java在这个上面性能太差，说明不了C#性能好)。
请“老赵们”以后不要天天在.NET社区里说“C#这个比Java好，那个比Java cool”，这就像天天告诉自己的孩子，你比你们班最后一名的那个孩子好多了，你说孩子还能学好吗???你怎么总拿C#跟差的比，不跟好的比呢?
最后结语
好，文章写完了，我希望.NET技术社区的“老赵们”围绕“反射的性能话题”来辩驳，不要扯别的话题来放烟雾弹(C#/.NET中别的技术话题，我会在下面的文章中一篇一篇来讨论，请大家耐心等待给我一点时间)。谢谢!
正要贴本文的时候，看到《关于C#开发山寨操作系统,程序语言,浏览器,IDE,Office,Photoshop等大型程序的可行性歪论及意义》http://www.cnblogs.com/DSharp/archive/2010/06/24/1764210.html 这篇文章。我的回答非常明确：没有任何可行性，且不论商业可行性、其他技术问题，光反射一项带来的两大性能负担就把路堵死了——这也是我前文说的那么多软件为什么不采用C#开发的一个关键原因——你搞一个100M的程序，中间有50M都是metadata，你还让人程序活下去吗?
(凡署名“IT168”的稿件均为本站原创，请在转载时注明出处及作者。非上述媒体稿件均系转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。转载者自负版权等法律责任。)
