今天周末，就不写太长的文章了，刚不小心看了篇性能比较的文章，有感而就写了此篇。
这年头，好多人都对性能比较产生了兴趣，然后就开始写比较示例，之后就得出了一个正确但误导新手的误区。
本文不是性能比较文章，只说说观点，没有具体的测试数据，相关的性能比较文篇，园子里一搜，都是一堆一堆的。
这里举较常见的说：
1：string和stringbuilder
2：反射和emit
3：==和string.equals
通常比较都怎么比？
1：写个测试示例
2：for它个10万百万次
3：看输出时间
4：得出结论
结论与“推荐”
后者速度比前者速度快了n倍，然后就开始“推荐”使用后者。
很多学者爱看比较性文章，然而内容他不看，就看“推荐”两字。
然后就盲目“推荐”给自己和周围的人士。
广泛“推荐”及人推人之后的现象
于是现在看很多人的代码，都喜欢：
动不动就来个stringbuilder。
动不动就来下emit。
动不动就来次string.equals。
看文章请认准性能临界点
什么是临界点，下面是一个精略的估算次数：
600次循环之前，string比stringbuilder快。
500次循环之前，反射比emit快。
90000000的循环，才换来：1.6392576秒和1.1163117秒间46.675%的性能差别。
应用应该看场景
别动不动就在stringbuiler，或以砖家的身份还在嫌人家的string+="xxx"慢。
别动不动就在emit，虽然写emit是个相对难以理解和编写的。
别动不动就在string.equals,难道你的代码真会循环9千万次？
简单说句是什么？
认准你的代码的应用场景，是否会产生大于n百次的临界点，再决定使用哪个。
再简单？
通常你的string循环不会超过600次,老实的用string+=“”。
通常你的list<t>的集合不会超过500条，老实的用反射。
通常你的==没什么问题，该用就用。
其它提示：object对象比较时，记得该用object.equals。
本文就到此结束了，欢迎有感者留言。
附加：
版权声明：本文原创发表于博客园，作者为路过秋天，原文链接：
http://www.cnblogs.com/cyq1162/archive/2011/05/08/2040294.html