编者按：性能优化，不仅需要对系统和代码熟悉，更需要一个强有力的工具支持。本文是性能优化系列文章的第三篇，从性能优化要考虑工具的哪些问题开始说起，到性能优化工具都有哪些？本文为您一一介绍。
“工欲善其事，必先利其器”(孔子)，虽然“思想比工具更重要”(弯曲网友)，但是，如果没有工具支持，性能优化就会非常累。思想不好掌握，但是使用工具还是比较好学习的，有了工具支持，可以让初级开发者更容易入门。
性能优化用到的工具，需要考虑哪些方面的问题?
1)使用工具是否需要重新编译代码?
一般来说，性能优化工具基本上都需要重新编译代码。因为在生产环境里面使用的image，应该是已经优化过的image。不应该在用户环境里面去调试性能问题。但Build-in的工具有一个好处就是性能测试所用的image和性能调试所用的image是相同的，这样可以避免重新编译所带来的误差。
2)工具本身对测量结果的影响
如果是Build-in的工具，需要减小工具对性能的影响，启用工具和不启用工具对性能的影响应该在一定范围之内，比如5%，否则不清楚是工具本身影响性能还是被测量的代码性能下降。
如果是需要重新编译使用的工具，这里的测试是一个相对值，不能做为性能指标的依据。因为编译会修改代码的位置，也可能会往代码里面加一个测量函数，它生成的image和性能测试的image不一样。
在这里要列出几个我用过的Linux工具，其他系统应该也有对应的工具，读者可以自己搜索。
性能测试工具一般分这么几种
1)收集CPU的performance counter。CPU里面有很多performance counter，打开之后，会记录CPU某些事件的数量，比如cache miss, 指令数，指令时间等等。这些counter需要编程才能使用。测量哪一段代码完全由自己掌握。
2)利用编译器的功能，在函数入口和出口自动加回调函数，在回调函数里面，记录入口和出口的时间。收集这些信息，可以得到函数的调用流程和每个函数所花费的时间。
3)自己在代码里面加入时间测量点，测量某段代码执行的时间。这种工具看起来和#1的作用差不多，但是由于performance counter编程有很多限制，所以这种工具有时还是有用处的。
在Linux里面，我们经常会用到
1)Oprofile
Oprofile已经加入了linux的内核代码库，所以不需要打patch，但是还需要重新编译内核才可以使用。这是使用最广泛的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
个人认为这是一个非常有用的工具，对读代码也有帮助，是居家旅行的必备。这里还有一个slide比较各种工具的，可以看看。
3) Performance counter
http://anton.ozlabs.org/blog/2009/09/04/using-performance-counters-for-linux/
Linux performance counter，用于收集CPU的performance counter，已经加入了内核代码库。通常来说，performance counter的粒度太大，基本没有什么用处，因为没法定位问题出在哪里;如果粒度太小，就需要手工编程，不能靠加几个检查点就可以了。所以还是要结合上面两个工具一起用才有好的效果。
工具解决哪些问题?
1)帮助建立基线。没有基线，就没办法做性能优化。性能优化是个迭代的过程，指望一次搞定是不现实的。
2)帮助定位问题。这里有两个涵义：一是性能问题出现在什么地方，是由哪一段代码引起的;二是性能问题的原因，cache miss，TLB miss还是其他。
3)帮助验证优化方案。优化的结果应该能在工具里面体现出来，而不是靠蒙。
【编辑推荐】
