性能优化的目标是什么?不外乎两个:
时间性能:减小系统执行的时间 空间性能:减小系统占用的空间
一、代码优化 做代码优化前,先了解下硬件Cache: (1)Cache Level:通常来说L1、L2的Cache集成在CPU里,L3的Cache放在CPU外; (2)Cache Size:它决定你能把多少东西放到Cache里,有Size就有竞争,就有替换,才有所谓优化的空间; (3)Cache Type:I-Cache(指令),D-Cache(数据),TLB(MMU的Cache);
代码层次的优化主要从以下两个角度考虑问题: (1)I-Cache优化:精简code path,简化调用关系,减少冗余代码等等; (2)D-Cache优化:减少D-Cache的miss数量,增加有效数据访问。
以下是一些技巧,可供参考: (1)Code adjacency(把相关代码放在一起) 这里有两层含义:一是相关源文件要放在一起;二是相关函数在object文件里面,也应该相邻。 这样,可执行文件被夹在到内存里时,函数位置也是相邻的,同事还符合模块化编程的要求:高内聚,低耦合。 (2)Cache line alignment(cache对齐) 对齐Cache以减少潜在的一次读写,但这可能意味着内存的浪费,需要从空间和时间两方面衡量。 (3)Branch prediction(分支预测) 如果能预测那段代码有更高的执行概率,就能减少跳转次数(调整if和else的顺序?)。 (4)Data prefetch(数据预取) 由CPU自动完成。 (5)Register parameters(寄存器参数) (6)Lazy computation(延时计算) 最近不用的变量,不要急着去初始化(意味着可能执行复杂的构造),如果某个分支跳出了函数,这些动作就浪费了。 COW(copy-on-write)就是一种延时计算的技术。 (7)Early computation(提前计算) 有些变量,计算一次就够了,任何加减乘除都会消耗CPU指令,尽量使用常数,而不是24*60*60来表示一天的秒数。 (8)Inline(内联函数) (9)Macro(宏定义) (10)Allocation on stack(局部变量) 避免在栈上申请大数组,其初始化和销毁的代价很高。 (11)Per-cpu data structure(非共享数据结构) 避免共享量的锁,在thread local里,多核情况下使用局部变量会带来好处。 (12)Reduce call path or call trace(减少函数调用层次) (13)Read&write split(读写分离) (14)Recude duplicated code(减少冗余代码)
其中,(1)(6)(7)(8)(9)(10)(11)(12)(14)这些优化方式最为常见。
二、工具优化 “工欲善其事,必先利其器”,如果没有工具的支持,性能优化难以实施,谁也不知道哪些地方是严重影响性能的主要矛盾。 使用性能优化的工具,需要考虑以下问题: (1)使用工具是否需要重新执行编译? (2)工具本身对测量结果的影响:工具对性能的影响必须在一个可接受的范围以内。
工具能解决的问题: (1)建立性能基线,以作对比; (2)帮助定位性能瓶颈; (3)帮助验证优化方案;
性能测试工具一般由这么几种: (1)收集CPU的性能计数; (2)利用编译器的功能,在函数入口和出口加回调函数; (3)在代码中加入时间测量点。
在Linux下,通常会用到的有: (1)Oprofile 它已经加入Linux内核代码库,但通常需要重新编译内核,参考如下 http://oprofile.sourceforge.net/news/ http://people.redhat.com/wcohen/Oprofile.pdf (2)KFT and Gprof KFT是kernel的一个patch,只对kernel有效;Gprof是gcc里面的一个工具,只对用户空间的程序有效。这两个工具都需要重新编译代码,它们都用到了gcc里面的finstrument-functions选项。编译时会在函数入口,出口加回调函数,而且inline函数也会改成非inline的。它的工作原理可以参考: http://blog.linux.org.tw/~jserv/archives/001870.html http://blog.linux.org.tw/~jserv/archives/001723.html http://elinux.org/Kernel_Function_Trace http://www.network-theory.co.uk/docs/gccintro/gccintro_80.html
三、系统优化 从系统层面去优化系统往往有更为明显的效果,优化之前,可以思考,是否能够通过扩展系统来达到提高性能的目的: (1)Scale up:使用更强的硬件; (2)Scale out:使用更多的组件;
如果升级硬件的方法就能解决问题,为什么还要使用修改代码,调整架构这样大风险的举措呢?(需要考虑成本) 以下是一些常用的系统优化的方法: (1)Cache Cache干什么?保存已经执行过的结果。 Cache为什么有效?避免已计算过的开销,获取更快的访问。 Cache的难点在哪里?一是快速匹配;二是Cache容量有效,需要较好的替换策略; Cache在哪些情况下有效?时间局部性。即当前计算的结果,后续有可能使用到,如果没有时间局部性,反而对架构有害。
(2)Lazy Computing 理念就是,不要做多余的事情,最常见的例子就是COW(copy-on-write): http://en.wikipedia.org/wiki/Copy-on-write COW干什么?写时复制。 COW为什么有效?节省内存复制时间,均匀内存分配时间。 COW的难点在哪里?一是引用计数的使用;二是确认哪些内存是可以共享的。
(3)read ahead/pre-fetch预读 http://en.wikipedia.org/wiki/Readahead 预读干什么?提前准备所需要的数据。 预读为什么有效?减少等待内存的时间,相当于把多个操作集合成一个。 预读在哪些情况下有效?空间局部性。
(4)Asynchronous异步 http://en.wikipedia.org/wiki/Asynchronous_I/O 异步干什么?异步是一种通信方式,请求与应答分离。 异步为什么有效?消除等待时间。 异步的难点是什么?如何实现分布式状态机,如何使用回调,使异步时间到达后继续执行。 异步在哪些情况下有效?状态之间不能有强依赖关系。
(5)Polling轮询 http://en.wikipedia.org/wiki/Polling_(computer_science)
(6)Static memory pool(内存池) http://en.wikipedia.org/wiki/Static_memory_allocation 内存池干什么?提前分配内存以获取更好的性能,只是适应性可能会降低,并可能造成内存浪费。 内存池为什么有效?避免重复内存申请、释放开销。 内存池的难点是什么?分配多大的内存池,如何避免浪费都是需要考虑的问题。 内存池在哪些情况下有效?一是固定大小的内存需求,二是快速的分配与释放需求。
四、总结 性能优化只是系统的一个方面,它可能会和系统的其他要求有冲突,比如 可读性:性能优化不能影响可读性,谁愿意维护不怎么漂亮的代码; 模块化:性能优化往往需要打破模块的边界,想想这是否值得; 可移植:隔离硬件相关的代码,尽量使用统一的API; 可维护:许多性能优化的技巧,会导致后来维护代码的人崩溃;
需要在性能优化和上述的几个要求之间做出tradeoff,不能一意孤行。