高性能软件法则

16-09-22 banq
         

学习如何编写高性能的代码是困难的。这里有一些简单的法律 :

1.程序语言 <<程序员的性能意识,编程语言并不重要,重要的是程序员必须意识了解语言的执行情况和相关库包,所有主流编程语言和它们的标准库都已经被充分优化,能够用来在更大范围应用领域编写高性能代码,也可以用来编写可怕的代码,所谓更好也可能更坏,高级语言会提供表面糖语法使得使用起来非常方便,但是你应该意识到它们会耗费大量内存,或者与输入大小有一个超线性关系。

2.小设计细节很关键,同一段代码两个版本的小区别可能导致巨大差异,有人也许已经从混沌系统中认识这个法则,是不是产生不必要的垃圾?正确缓存了吗?你尽早摆脱了无用的网络数据包/请求吗?过度使用序列化或使用一个缓慢的序列化?你的字典太大了,效率不高吗?在高级语言中,除非你的设计破裂,否则不需要代码很大的修改以获得更好性能,非常小的代码修改也许会有巨大性能变化,比如,缓存能在10 LOC内加入,字符串使用String builder,过滤器可以只用几行加入即可,小代码修改,大效果。

3. corr(性能退化,无限资源使用)>0.9,在性能退化,崩溃和无限的使用资源之间有一个非常高的相关性,从小应用到健壮程序,会经历各种不可控输入的剧烈考验,这需要我们更加关注操作而不是功能,当你不限制资源使用,它们就可能耗尽资源,你启动了ad-hoc线程?使用固定数量的线程池?需要快速内存字典吗?使用有界的缓存。线程之间传输数据吗?使用堵塞队列,其容量必须是数据最大值,这样不会耗尽内存。你的程序从文件系统读取文本数据?不要使用readline,除非你确认行有合理的大小,限制,限制,限制,不要无限使用资源,或你的程序在过了某个阀值以后性能急剧下降。

4.程序性能提高=日志(可控经验),很多人不能问答:这个函数实际运行多长时间?这个数据结构会耗费多少内存。当务之急是建立一个小型,可控基准测试,以此确认解决性能瓶颈,如果你不知道瓶颈在哪里,可以通过各种profiler工具,但是常常是一小部分代码是瓶颈,需要仔细微调,大部分和性能无关,小部分关键会贡献90%的性能价值。

5.N*bad 不等于 good,有些人期望使用多核服务器,map-reduce集群,HPC和大内存服务器,这些都是为了让软件跑得更快,反而忽视在小内存单核下的微调,在单核小内存情况下代码不执行或崩溃,即使移植到更强大硬件上也无济于事。

Laws of Performant Software | Tagide

         

2