关于性能比较的使用误区

关于性能比较的应用误区

这年头,好多人都对性能比较产生了兴趣,然后就开始写比较示例,之后就得出了一个正确但误导新手的误区。

 

本文不是性能比较文章,只说说观点,没有具体的测试数据,相关的性能比较文篇,园子里一搜,都是一堆一堆的。

 

这里举较常见的说:

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。

1 楼 greatrobert 2011-05-13  
这个观点有对也有不对,你说的循环多少次只是系统中只有这一段代码在跑的情况下才成立的,在真实环境中在短时间内是有很多程序在运行,很多线程。。。这个时候跟循环很多次效果是一样的,String的拼接一样会引起对象过多而进行垃圾回收,导致性能下降。明白了String加号拼接慢的原因就可以了。