首页 / 更多教程 / 性能优化的方法和技巧：代码
性能优化的方法和技巧：代码
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了性能优化的方法和技巧：代码，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含10504字，纯文字阅读大概需要16分钟。
内容图文
转载自https://blog.csdn.net/xiongping_/article/details/43953241
性能优化的方法和技巧：代码
本文是弯曲大牛KernelChina所写，非常不错，在这里和大家分享一下。
代码层次的优化是最直接，也是最简单的，但前提是要对代码很熟悉，对系统很熟悉。很多事情做到后来，都是一句话：无他，但手熟尔^-^。
在展开这个话题之前，有必要先简单介绍一下Cache相关的内容，如果对这部分内容不熟悉，建议先补补课，做性能优化对Cache不了解，基本上就是盲人骑瞎马。
Cache的关注点
Cache一般来说，需要关心以下几个方面
1）Cache hierarchy
Cache的层次，一般有L1, L2, L3 （L是level的意思）的cache。通常来说L1，L2是集成 在CPU里面的（可以称之为On-chip cache），而L3是放在CPU外面（可以称之为Off-chip cache）。当然这个不是绝对的，不同CPU的做法可能会不太一样。这里面应该还需要加上 register，虽然register不是cache，但是把数据放到register里面是能够提高性能的。
2）Cache size
Cache的容量决定了有多少代码和数据可以放到Cache里面，有了Cache才有了竞争，才有 了替换，才有了优化的空间。如果一个程序的热点(hotspot)已经完全填充了整个Cache，那 么再从Cache角度考虑优化就是白费力气了，巧妇难为无米之炊。我们优化程序的目标是把 程序尽可能放到Cache里面，但是把程序写到能够占满整个Cache还是有一定难度的，这么大 的一个Code path，相应的代码得有多少，代码逻辑肯定是相当的复杂（基本上是不可能，至少 我没有见过）。
3）Cache line size
CPU从内存load数据是一次一个cache line；往内存里面写也是一次一个cache line，所以一个 cache line里面的数据最好是读写分开，否则就会相互影响。
4）Cache associative
Cache的关联。有全关联(full associative)，内存可以映射到任意一个Cache line；也有N-way 关联，这个就是一个哈希表的结构，N就是冲突链的长度，超过了N，就需要替换。
5）Cache type
有I-cache（指令cache），D-cache（数据cache），TLB（MMU的cache），每一种又有L1, L2等等，有区分指令和数据的cache，也有不区分指令和数据的cache。
更多与cache相关的知识，可以参考这个链接：
http://en.wikipedia.org/wiki/CPU_cache
或者是附件里面的cache.pdf，里面有一个简单的总结。
代码层次的优化
主要是从以下两个角度考虑问题：
1）I-cache相关的优化
例如精简code path，简化调用关系，减少冗余代码等等。尽量减少不必要的调用。但是有用还是无用，是和应用相关的，所以代码层次的优化很多是针对某个应用或者性能指标的优化。有针对性的优化，更容易得到可观的结果。
2）D-cache相关的优化
减少D-cache miss的数量，增加有效的数据访问的数量。这个要比I-cache优化难一些。
下面是一个代码优化技巧列表，需要不断地补充，优化和筛选。
1) Code adjacency （把相关代码放在一起），推荐指数：5颗星
把相关代码放在一起有两个涵义，一是相关的源文件要放在一起；二是相关的函数在object文件 里面，也应该是相邻的。这样，在可执行文件被加载到内存里面的时候，函数的位置也是相邻的。 相邻的函数，冲突的几率比较小。而且相关的函数放在一起，也符合模块化编程的要求：那就是 高内聚，低耦合。
如果能够把一个code path上的函数编译到一起（需要编译器支持，把相关函数编译到一起）， 很显然会提高I-cache的命中率，减少冲突。但是一个系统有很多个code path，所以不可能面 面俱到。不同的性能指标，在优化的时候可能是冲突的。所以尽量做对所以case都有效的优化， 虽然做到这一点比较难。
2) Cache line alignment （cache对齐），推荐指数：4颗星
数据跨越两个cache line，就意味着两次load或者两次store。如果数据结构是cache line对齐的， 就有可能减少一次读写。数据结构的首地址cache line对齐，意味着可能有内存浪费（特别是 数组这样连续分配的数据结构），所以需要在空间和时间两方面权衡。
3) Branch prediction （分支预测），推荐指数：3颗星
代码在内存里面是顺序排列的。对于分支程序来说，如果分支语句之后的代码有更大的执行几率， 那么就可以减少跳转，一般CPU都有指令预取功能，这样可以提高指令预取命中的几率。分支预测 用的就是likely/unlikely这样的宏，一般需要编译器的支持，这样做是静态的分支预测。现在也有 很多CPU支持在CPU内部保存执行过的分支指令的结果（分支指令的cache），所以静态的分支预测 就没有太多的意义。如果分支是有意义的，那么说明任何分支都会执行到，所以在特定情况下，静态 分支预测的结果并s没有多好，而且likely/unlikely对代码有很大的侵害（影响可读性），所以一般不 推荐使用这个方法。
4) Data prefetch (数据预取），推荐指数：4颗星
指令预取是CPU自动完成的，但是数据预取就是一个有技术含量的工作。数据预取的依据是预取的数据 马上会用到，这个应该符合空间局部性（spatial locality），但是如何知道预取的数据会被用到，这个 要看上下文的关系。一般来说，数据预取在循环里面用的比较多，因为循环是最符合空间局部性的代码。
但是数据预取的代码本身对程序是有侵害的（影响美观和可读性），而且优化效果不一定很明显（命中 的概率）。数据预取可以填充流水线，避免访问内存的等待，还是有一定的好处的。
5) Memory coloring （内存着色），推荐指数：不推荐
内存着色属于系统层次的优化，在代码优化阶段去考虑内存着色，有点太晚了。所以这个话题可以放到 系统层次优化里面去讨论。
6）Register parameters （寄存器参数），推荐指数：4颗星
寄存器做为速度最快的内存单元，不好好利用实在是浪费。但是，怎么用？一般来说，函数调用的参数 少于某个数，比如3，参数是通过寄存器传递的（这个要看ABI的约定）。所以，写函数的时候，不要 带那么多参数。c语言里还有一个register关键词，不过通常都没什么用处（没试过，不知道效果，不过 可以反汇编看看具体的指令，估计是和编译器相关）。尝试从寄存器里面读取数据，而不是内存。
7) Lazy computation （延迟计算），推荐指数：5颗星
延迟计算的意思是最近用不上的变量，就不要去初始化。通常来说，在函数开始就会初始化很多数据，但是 这些数据在函数执行过程中并没有用到（比如一个分支判断，就退出了函数），那么这些动作就是浪费了。
变量初始化是一个好的编程习惯，但是在性能优化的时候，有可能就是一个多余的动作，需要综合考虑函数 的各个分支，做出决定。
延迟计算也可以是系统层次的优化，比如COW(copy-on-write)就是在fork子进程的时候，并没有复制父 进程所有的页表，而是只复制指令部分。当有写发生的时候，再复制数据部分，这样可以避免不必要的复制， 提供进程创建的速度。
8] Early computation （提前计算），推荐指数：5颗星
有些变量，需要计算一次，多次使用的时候。最好是提前计算一下，保存结果，以后再引用，避免每次都 重新计算一次。函数多了，有时就会忽略这个函数都做了些什么，写程序的人可以不了解，但是优化的时候 不能不了解。能使用常数的地方，尽量使用常数，加减乘除都会消耗CPU的指令，不可不查。
9）Inline or not inline （inline函数），推荐指数：5颗星
Inline or not inline，这是个问题。Inline可以减少函数调用的开销（入栈，出栈的操作），但是inline也 有可能造成大量的重复代码，使得代码的体积变大。Inline对debug也有坏处（汇编和语言对不上）。所以 用这个的时候要谨慎。小的函数（小于10行），可以尝试用inline；调用次数多的或者很长的函数，尽量不 要用inline。
10) Macro or not macro (宏定义或者宏函数），推荐指数：5颗星
Macro和inline带来的好处，坏处是一样的。但我的感觉是，可以用宏定义，不要用宏函数。用宏写函数， 会有很多潜在的危险。宏要简单，精炼，最好是不要用。中看不中用。
11) Allocation on stack （局部变量），推荐指数：5颗星
如果每次都要在栈上分配一个1K大小的变量，这个代价是不是太大了哪？如果这个变量还需要初始化（因 为值是随机的），那是不是更浪费了。全局变量好的一点是不需要反复的重建，销毁；而局部变量就有这个 坏处。所以避免在栈上使用数组等变量。
12) Multiple conditions （多个条件的判断语句），推荐指数：3颗星
多个条件判断时，是一个逐步缩小范围的过程。条件的先后，决定了前面的判断是否多余的。根据code path 的情况和条件分支的几率，调整条件的顺序，可以在一定程度上减少code path的开销。但是这个工作做 起来有点难度，所以通常不推荐使用。
13) Per-cpu data structure (非共享的数据结构），推荐指数：5颗星
Per-cpu data structure 在多核，多CPU或者多线程编程里面一个通用的技巧。使用Per-cpu data structure的目的是避免共享变量的锁，使得每个CPU可以独立访问数据而与其他CPU无关。坏处是会 消耗大量的内存，而且并不是所有的变量都可以per-cpu化。并行是多核编程追求的目标，而串行化 是多核编程里面最大的伤害。有关并行和串行的话题，在系统层次优化里面还会提到。
局部变量肯定是thread local的，所以在多核编程里面，局部变量反而更有好处。
14) 64 bits counter in 32 bits environment （32位环境里的64位counter），推荐指数：5颗星
32位环境里面用64位counter很显然会影响性能，所以除非必要，最好别用。有关counter的优化可以多 说几句。counter是必须的，但是还需要慎重的选择，避免重复的计数。关键路径上的counter可以使用 per-cpu counter，非关键路径(exception path）就可以省一点内存。
15) Reduce call path or call trace （减少函数调用的层次），推荐指数：4颗星
函数越多，有用的事情做的就越少（函数的入栈，出栈等）。所以要减少函数的调用层次。但是不应该 破坏程序的美观和可读性。个人认为好程序的首要标准就是美观和可读性。不好看的程序读起来影响心 情。所以需要权衡利弊，不能一个程序就一个函数。
16) Move exception path out （把exception处理放到另一个函数里面），推荐指数：5颗星
把exception path和critical path放到一起（代码混合在一起），就会影响critical path的cache性能。 而很多时候，exception path都是长篇大论，有点喧宾夺主的感觉。如果能把critical path和 exception path完全分离开，这样对i-cache有很大帮助。
17) Read, write split （读写分离），推荐指数：5颗星
在cache.pdf里面提到了伪共享(false sharing)，就是说两个无关的变量，一个读，一个写，而这 两个变量在一个cache line里面。那么写会导致cache line失效（通常是在多核编程里面，两个变量 在不同的core上引用）。读写分离是一个很难运用的技巧，特别是在code很复杂的情况下。需要 不断地调试，是个力气活（如果有工具帮助会好一点，比如cache miss时触发cpu的execption处理 之类的）。
18) Reduce duplicated code（减少冗余代码），推荐指数：5颗星
代码里面的冗余代码和死代码(dead code)很多。减少冗余代码就是减小浪费。但冗余代码有时 又是必不可少（copy-paste太多，尾大不掉，不好改了），但是对critical path，花一些功夫还 是必要的。
代码优化有时与编程规则是冲突的，比如直接访问成员变量，还是通过接口来访问。编程规则上肯定是说要通过接口来访问，但直接访问效率更高。还有就是许多ASSERT之类的代码，加的多了，也影响性能，但是不加又会给debug带来麻烦。所以需要权衡。代码层次的优化是基本功课，但是指望代码层次的优化来解决所有问题，无疑是缘木求鱼。从系统层次和算法层次考虑问题，可能效果会更好。
代码层次的优化需要相关工具的配合，没有工具，将会事倍功半。所以在优化之前，先把工具准备好。有关工具的话题，会在另一篇文章里面讲。
还有什么，需要好好想想。这些优化技巧都是与c语言相关的。对于其他语言不一定适用。每个语言都有一些与性能相关的编码规范和约定俗成，遵守就可以了。有很多Effective, Exceptional 系列的书籍，可以看看。
代码相关的优化，着力点还是在代码上，多看，多想，就会有收获。
参考资料：
1）http://en.wikipedia.org/wiki/CPU_cache
2) Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)
3) More Effective C++: 35 New Ways to Improve Your Programs and Designs
4) Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library
5) Effective Java (2nd Edition)
权限： 公开???来自：labs 声明： 本文仅代表作者个人观点。其原创性及文中表达的意见、判断、数据、观点和陈述文字等内容均与中国移动研究院无关。移动Labs博客致力于为ICT领域的研究者及从业者提供技术和业务交流的网络平台，对本文中全部或部分内容的真实性、完整性不作任何保证或承诺，仅供读者参考交流。
内容总结
以上是互联网集市为您收集整理的性能优化的方法和技巧：代码全部内容，希望文章能够帮你解决性能优化的方法和技巧：代码所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。