一个困扰了我很久的问题,算是程序优化方面的?

Z_wenuw 发布于 2013/05/21 10:44
阅读 597
收藏 0
偶尔,我会纠结于诸如一个if判断我要付出的代价是多少这种问题,比如有好几个条件,那么我是分开写或者写一起效率高?

一时也想不到案例。总之就是我不同的操作要付出的代价有多大,多种实现方案的时候怎样知道哪种运行效率最高(同样健壮)……

似乎是一些细枝末节,费力不讨好的追求,但是很多时候我就是在这上面迷茫。想请教前辈们怎么破,或者该看哪些方面,那几本书呢?

不仅仅是Java中……

对了。比如某个方法返回一个List,需要循环执行若干次,我是声明一个作用域更广的List变量来接受返回值呢,还是在适当的作用域接受返回值,更广的话,我就要每次循环执行结束后将其置为null以便下次使用,但是如果适当作用域的话 我每次都要声明一个局部变量。改如何取舍?

前辈们给点意见吧~

加载中
0
王瑞平
王瑞平

岂不闻时间复杂度和空间复杂度?

对算法就是权衡这两个方面,找个最好办法

Z_wenuw
Z_wenuw
非本科出身没学过啊。个人感觉这两个是对于宏观上的描述。就拿我这里来说,得到时间复杂度,总需要几个判断的标准 比如list l1 一下的时间是3点,引用指向新的对象是5点,那么可以说3点的时间复杂度为……更省时间。也不知道我这么想对不对。如果前面我的理解差不多,那么我现在就是在纠结这个判断的标准并不知道。
0
梅开源
梅开源

1. 多看比较效率的软件的代码,则自然而然该写成什么样八九不离十。

2. 一般不是做竞争激烈的产品的话,没必要过于纠结怎样的效率更高。学校里教的东西过于纠结局部优化,但没告诉学生,当一个程序写到90分的逻辑,已经足够健壮,再去追求面面俱到好上加好要花多大的代价甚至是不可能完成的任务。应该把思路转换过来以追求更高产出,你用一个小时,与其写一小段程序然后优化再优化,不如写三段程序形成一个更强大的程序(包)。

3. 效率很多时候是次要问题的。本身编程语言速度不慢,算法不是太烂,剩下的事情就是交给机器暴力解决。

Z_wenuw
Z_wenuw
谢谢~ 读优秀的源码我怎么就没想到呢。
0
梅开源
梅开源
对效率实在纠结的话找些“高性能xxxx”, 算法书籍,以及JVM的书看,找benchmark工具。
Z_wenuw
Z_wenuw
回复 @梅开源 : 谢谢~
梅开源
梅开源
回复 @Z_wenuw : 到z.cn搜高性能,然后选图书类滤去不是书的商品。再搜个JVM.
Z_wenuw
Z_wenuw
高性能XX,前辈有具体点的推荐么,感觉国内好多书都写得有点……JVM的书籍?是编译原理那方向的?
0
Monkey
Monkey
效率就是内核和cpu之间均衡的一个选择。
Z_wenuw
Z_wenuw
不是很明白额~
0
clt
clt

不必纠结一般的操作,一般的语句不够成性能问题。 

不是作算法的话,避开常见的耗时操作,减少一些不必要的运算就可以了。  

大部分的性能其实都在 IO , 整个逻辑怎么组织上。    

多一个赋值,少一个赋值,应用跑上一天也不一定能差上 1 秒来。

Z_wenuw
Z_wenuw
原来多一个少一个赋值的代价这么小……
0
小耶果
小耶果
搜索以前的帖子,有过讨论.不过站在纯应用的角度,或者说非汇编/C/C++这些native语言追求细微的优化成效不大,因为真正拖慢效率的瓶颈不再讨论的这些优化技术范围内.
Z_wenuw
Z_wenuw
回复 @小耶果 : 谢谢~!
小耶果
小耶果
回复 @Z_wenuw : 本站搜索流水线和性能优化
Z_wenuw
Z_wenuw
以前的帖子,求赐个线索吧。其实我是想知道这些,然后融入到自己的习惯中,随手就写出了更优的代码,哪怕微不足道的优。
0
Tuesday
Tuesday

十个判断条件并行, 我现在也在头痛.

if else似乎很不爽.

0
amonxu
amonxu

1.多看开源的项目,读别人的代码,久而久之你自己想不学到都难。

2.性能这个东西没必要太纠结,现在硬件这么强,真正代码能做到的优化还是有局限的。你可以了解一下算法相关的,在写代码的时候心中能做到有底。

0
梅开源
梅开源

引用来自“Tuesday”的答案

十个判断条件并行, 我现在也在头痛.

if else似乎很不爽.

这个的确不爽,很深的if else都像是个决策树了。

当时汉就来了
当时汉就来了
可以用策略模式 把代码封装一下,这样可以规避很多if else
0
小耶果
小耶果

      语言层面/指令级的优化技巧在80/90年代最为盛行,那时硬件速度很慢,资源很有限,内存只有256k,那个时代写代码都要精心策划每个bit的使用,flag就是那时代的产物.

      在FC的硬件条件下要同屏显示十几个Sprite是需要相当技巧的.定点数/查表法/等等都是那时候盛行的优化.但随着时代的进步,机器硬件突飞猛进,某些优化技巧已经不适应,比如定点数,有些则起到相反作用.

      现代技术更注重的是算法的优化,比如图形学领域,只会尝试更优算法,而鲜有人尝试代码级别的优化(有一定效果,前提是原版写得太烂).用汇编写的冒泡排序再如何也比不过用Python写的快速排序.

      现代编译器技术的优化已很成熟,一般的优化技巧编译器全都替你代劳了.比如全局变量的存取要慢于局部变量,但编译器发现反复存取同一全局变量,再侦测没有副作用外也会进行一定的优化使得访问也进入cache中,if else过多,编译器会进行hash加跳转表等等,所以除非算法已经达到最优,效率还是不够再考虑这些细节优化,否则花大力气得小便宜.

      更复杂的事每个平台,硬件,cpu,编译器这些优化技巧不一定全部适用.要不断比较尝试才行.

Z_wenuw
Z_wenuw
谢谢你,看来我以前的方向有点小问题。
返回顶部
顶部