关于性能优化

我发现一个现象，很多两三年以下的人写代码动不动就扯性能，其实他们大部分人根本不知道到底哪是性能瓶颈，函数调用的效率，CPU执行指令需要的时间...工作效率低不说，还考虑很多没用的东西。个人感觉，性能这个东西应该考虑：
1.考虑程序的应用范围。如果你是给核反应堆写实时程序，那每一步你可能都得考虑，其他就大部分通用程序而言，你不用每一步都考虑。
2.性能要考虑关键瓶颈。不是每一步都是关键，关键瓶颈不是写之前提前考虑出来的，而是测出来的。很多你以为瓶颈的地方往往不是瓶颈。
3.低效的算法+大量的处理数据两者结合往往是导致效率低下的根本原因，而函数调用，拆分函数等不是。JAVA初学者喜欢怀疑函数调用，C++派则彻底怀疑继承结构和堆上的数据，很有意思的现象。即使低效的算法处理小量数据也没必要优化，e.g.冒泡排序和快速排序在排少量数据的时候的性能差异不需要考虑。

大家说说自己的看法。

P.S.编程里面真的有很多不符合直觉的结论。比如边开发边考虑性能优化是否必要，比如添加人手是否能提高项目进度，真的是很有意思。

评论

155 楼 HuangSui.cn 2011-01-30  

抛出异常的爱 写道

PS:楼上几个不是在开 我玩笑么?

项目中没有这样用，接触的项目也不多，3Q!

154 楼 ppgunjack 2011-01-28  

如果你从初学者就开始一直坚持优化，肯定不是坏事，慢慢就会懂得那些地方不值得优化，那些地方需要付出复杂度来换取性能，程序的性能最后总是是追求平衡的结果，不要优化就是另一个极端
写代码至少弄清楚机器能到什么性能，自己的应用到了什么性能。见过的几乎绝大多数性能问题都是设计和实现的问题，真要调优，OS和数据库层面的调优已经是最后的活命稻草，救回来也属于苟延残喘，让整个部署更加复杂和丑陋
所以老外有哪些专门写core的和写外围的coder的区别，那些大牛细节知识已经足够让他们不写低效代码，所以提倡尽量不优化
他们所写的effective xx目的就是要你注意细节再注意细节，哪些细节是高效可靠的，他们不提倡优化是因为已经把类似的这些条条框框都融入到骨子里了
coder不是项目经理，政治家，ceo，搞什么战略，更像开刀的，不是什么地方都随你放血，随你割，动完刀子再给你调优，有些关键的细节你就是旁边递钳子的也要懂，当然如果一辈子都决心要杀猪这个是过分了

153 楼 ironsabre 2011-01-28  

1，许多计算机方面的错误都是因为进了没有必要的优化而导致的，包括一些极度愚蠢的错误；
2，不要为了一些细小的效率提升而进行优化，据说97%的情况下不成熟的优化行为才是万恶之源；
3，时刻记得2个优化原则：不要优化；除非你有了一个明确和可行的优化方案。

152 楼 抛出异常的爱 2011-01-28  

ironsabre 写道

iaimstar 写道

我记得啥书来着

里面说 优化的第一原则

不要优化

这么说是因为低水平的选手太多了，怕大家乱搞。
真正的高手不受这个原则限制。

你确认看过第二句么?
要不要我把页码告诉你你再过去看看第二行写的是什么 ?


PS:很多toString方法是eclipse生成的,
还有toString是用Common lang toStringBuilder反射出来的.
集合包里的listtostring就是底归的....
没有外面的if(isDebug) 这些toString方法会被 + 号所触发.
在hibernate里轻轻松松破掉lazy load

当然这都是极端情况.
尽量不要写这种可能有问题而且无意义的代码才是我主要要说的....

如果需要至少要把这种代码包装起来.....

class MyLogZ{

 public static void DEBUG(Logger log , Object .... message){
    if(log.isDebug())return;
    StrinBuilder buffer = new StringBuilder();
    for(Object o message){
          buffer.appand(""+o);
    }
    log.debug(buffer.toString());
 }

}

战略不战略我不知道.
规则必有因.
去掉规则也有很多办法

151 楼 ironsabre 2011-01-28  

iaimstar 写道

就像前面老抛说的，优化这个东西，是否真的能带来优
是尚未可知的问题，过早的优化和盲目的优化都是扯淡

这和高不高手没有关系，在没有成为真正的性能瓶颈之前就考虑折磨大脑

即使高手也忙不过来

在保证了逻辑模型的正确性后，再对系统性能的瓶颈进行调优，才能把优化造成危害的可能性降低。

战略永远高于战术，到哪都一样，高手应该是战略高手，而不是战术高手

高手知道什么时候要做什么。如果连你能想到的东西高手都想不到的话，那怎么还能称为高手呢？
明白了？

150 楼 iaimstar 2011-01-28  

就像前面老抛说的，优化这个东西，是否真的能带来优
是尚未可知的问题，过早的优化和盲目的优化都是扯淡

这和高不高手没有关系，在没有成为真正的性能瓶颈之前就考虑折磨大脑

即使高手也忙不过来

在保证了逻辑模型的正确性后，再对系统性能的瓶颈进行调优，才能把优化造成危害的可能性降低。

战略永远高于战术，到哪都一样，高手应该是战略高手，而不是战术高手

149 楼 ironsabre 2011-01-28  

iaimstar 写道

我记得啥书来着

里面说 优化的第一原则

不要优化

这么说是因为低水平的选手太多了，怕大家乱搞。
真正的高手不受这个原则限制。

148 楼 cectsky 2011-01-28  

iaimstar 写道

我记得啥书来着

里面说 优化的第一原则

不要优化

effective java  不是不要优化，是尽可能不去优化

147 楼 iaimstar 2011-01-27  

我记得啥书来着

里面说 优化的第一原则

不要优化

146 楼 dengtl 2011-01-27  

Cache & Batch + 基于测试数据（如JProfile）这是性能优化的基本法则！

145 楼 mercyblitz 2011-01-27  

看朋友们都在讨论代码级别的优化，我觉得很大程度上面，代码上面的优化是最后的优化。通过修改系统I/O、内核等参数、Java编译参数，JVM运行时参数、同时调整数据策略的话，远比修改代码来得直接。

再说，合格的高级（成熟）工程师而言，在代码编写的时候，应该具备这样的能力，并且思维的周密性和做事的方法，提高代码质量和效率。

至于Integer i = new Integer(20); 、Integer i =Integer.valueOf(20)，还是Integer i = 20; JSL约定后两者效率一样。类似与这类Integer的对象属于简单对象，构造一个是纳秒级别的事情。当然，成熟的工程师应该知道的，:-)。

144 楼 mercyblitz 2011-01-27  

抛出异常的爱 写道

cectsky 写道

HuangSui.cn 写道

if(log.isDebug()){
   log.debug("xxxx"+bean+"xxxxx");
}

这样有什么问题？

多次一举

从架构师的角度的的确确不是多此一举


bean的toString方法可能会产生底归性的数据大查询,遍历所有的节点大于几百上千也常 常 见到

更有可能会产生对blob字段的数据日志输出

我说的是把这行代码 这样的代码 都 删了.
这种debug是没必要的存在.
这种没有作用的!
隐藏着可能会产生严重问题的代码!
(以至于必须用编程规范约束的代码)!
的出现就是对系统,自己,同事,客户的不负责任.


PS:楼上几个不是在开 我玩笑么?

看场景，大多数Bean是Thin 的，如果是Rich的话，可以换方法，或者修改toStrnig的约束。

再说debug的日志级别要开放，产品上一般不开放，对客户来说不那么重要。

143 楼 抛出异常的爱 2011-01-26  

cectsky 写道

HuangSui.cn 写道

if(log.isDebug()){
   log.debug("xxxx"+bean+"xxxxx");
}

这样有什么问题？

多次一举

从架构师的角度的的确确不是多此一举


bean的toString方法可能会产生底归性的数据大查询,遍历所有的节点大于几百上千也常 常 见到

更有可能会产生对blob字段的数据日志输出

我说的是把这行代码 这样的代码 都 删了.
这种debug是没必要的存在.
这种没有作用的!
隐藏着可能会产生严重问题的代码!
(以至于必须用编程规范约束的代码)!
的出现就是对系统,自己,同事,客户的不负责任.


PS:楼上几个不是在开 我玩笑么?

142 楼 cectsky 2011-01-26  

HuangSui.cn 写道

if(log.isDebug()){
   log.debug("xxxx"+bean+"xxxxx");
}

这样有什么问题？

多次一举

141 楼 HuangSui.cn 2011-01-26  

if(log.isDebug()){
   log.debug("xxxx"+bean+"xxxxx");
}

这样有什么问题？

140 楼 ppgunjack 2011-01-14  

关于函数化的成本，看你处在什么场景，当年bj就是靠讨这个的便宜用c++打击了c，并且也是因为避免虚函数和继承的成本诞生了mfc那几个高效但是招人骂的宏

139 楼 ppgunjack 2011-01-14  

大循环内的考虑效率，大循环外的考虑可读
所有可能阻塞和会导致时间复杂度的地方都要注意效率，其他地方慢点就慢点好了
另外程序设计外的部分一定要考虑导致的软硬件cache命中率，单位时间磁盘随机读写次数，几次随机物理读写可能就让你大部分代码优化化成灰
如果真的从新手开始就考虑性能，绝对不是坏事，往后几年比那些不在乎性能的老人写出的应用块100-1000倍很有可能
有句话，写程序先让它可运行，然后正确运行，最后让它快速运行，千万别信。人和人能力是不一样的，说这话的人闭着眼睛写的代码都比我们多数人快，大部分人是没这天赋的，多想多写只有好处

138 楼 bitray 2010-12-31  

ouchxp 写道

bitray 写道

呃，或许小弟表达有所不明确。我没有别的意思的，真的。就是说可能想多了有时候容易迷糊，有时候容易顿悟。呵呵
如果表达不清楚的地方，兄弟海涵

同是电信.你懂的.

我现在也是进入电信行业了。可惜我一直在电信业务以外的系统里奔波。悲惨的每一天啊

137 楼 ouchxp 2010-12-31  

bitray 写道

呃，或许小弟表达有所不明确。我没有别的意思的，真的。就是说可能想多了有时候容易迷糊，有时候容易顿悟。呵呵
如果表达不清楚的地方，兄弟海涵

同是电信.你懂的.

136 楼 bitray 2010-12-31  

抛出异常的爱 写道

bitray 写道

ouchxp 写道

bitray 写道

赞成2楼和三楼的观点。虽然可能平时大家注意的并不是真正的性能瓶颈。但是如果不重视自己代码的书写规范和简洁，那么写出来的代码就是隐藏的瓶颈，是你最后很难优化出来的东西。有习惯的程序员用stringbuffer和stringbuilder，但是如果是不重视，就会有人用+连接，在多处，一定数据量的情况下，都可能产生隐含问题等

JDK自己已经有优化了. 不合理的优化反而会降低效率
比如字符串常量拼接

String str ="aaa" + "bbb" +"ccc" + "ddd";

StringBuilder sb = new StringBuilder();
sb.append("aaa");
sb.append("bbb");
sb.append("ccc");
sb.append("ddd");
String str = sb.toString();

哪种效率高? 答案是第一种. 对于新手来说想优化很容易适得其反.
反编译看一下就知道为什么了.

第一种链接其实是在欺骗自己。这个根本就是一个字符串。jvm必然会进行优化。你要是用变量进行连接你试试？马上就不是一个性能级别。
我不反对你说的新手容易产生误区，但是其实良好的编程习惯和严格的步骤，总是对人成长有好处的。多思考一下，总比少想一点要好嘛。虽然容易造成过度设计，但是一旦走出来就会豁然开朗。

PS，其实我也是新手没工作3，4年。我没有痴迷到研究哪个API更好，但是也希望写出来更简洁的代码

行数不上千的string 拼接就是浮云怎么简单怎么来

if(log.isDebug()){
   log.debug("xxxx"+bean+"xxxxx");
}

像这样的代码删了吧...不然恶心的饭都要吐出来

向抛哥致敬，感谢抛哥经常回答小弟的问题。