嵌入式应用的优化技巧

  软件的优化得看使用的频率,像一些软件用户不怎么用,使用率并不高的这些软件根本就没有必要优化。而对于有些应用,软件性能的不佳或许在每分每秒钟能够流失成千上万个流量。因此工程师们为了将系统的性能和流量哪怕提升一点点,都须要花费大量的时间。尽管在优化过程当中有许多的方法和技巧。但万变不离其总,总有一些通用的技巧值的咱们去借鉴。性能优化

  技巧1—老是建立基准用于比较函数

  建立基准用于比较优化结果的必要性显而易见,使人惊讶的是开发团队经常在没有任何基准的状况下匆忙开展优化。基准测量很重要,由于每次优化获得的改进会愈来愈小。举例来讲,第一遍能耗优化可能有20%的改进,第二次有10%,第三次5%,以此类推。开发人员应了解这种趋势,并将他们在系统中得到的改进量化为输入次数的函数。工具

  技巧2—设定优化目标性能

  每一次优化都比前一次须要更多的时间才能从系统中得到极少许的改进。开发团队须要仔细平衡他们的时间投入,并根据改进结果判断是否值得花这么多时间。一味闷头作事很容易沉迷,可能花了数周时间才认识到本身在优化一个再也不须要优化的系统。所以在优化开始以前,开发团队应设定一个目标值,达到这个目标,就表示优化结果对当前应用来讲足够好,优化过程已经完成。学习

  技巧3—使用正确的测量工具测试

  若是没有合适的测量工具,优化一个系统是很困难的。举例来讲,若是不使用一种精确的方法来测量系统和微控制器的能耗,便很难完成能耗的优化。开发人员常常没法区分这两种不一样的能量测量,他们试图减小实际上没法再减小的微控制器能耗。优化

  对性能优化感兴趣的开发人员能够看一看我在“亲自动手:Segger系统查看工具”中介绍的Segger系统查看工具,这款工具对于了解哪些 函数正在独占CPU很是有用。若是没有可以精确测量或可供开发人员查看系统行为的工具,那么在优化系统时便抓不住重点。blog

  技巧4—使用优化工具资源

  为了减少代码大小或提升性能,嵌入式软件的许多方面均可以优化。一些状况下可使用独立的或附属的工具链。Somnium DRT优化器就是一种很好的优化工具,能够与GCC一块儿用来优化代码大小、能量使用率和性能。开发

  不过有时候外部工具可能不是必需的,只要选择正确的工具链就足够了。我最近写了一篇题为《开源与商用编译器》的文章,说明了这样一个事实:在Coremark测试中,对于相同的微控制器和相同的测试条件,商用编译器的得分老是高于GCC等开源编译器。

  技巧5—使用编译器属性和#pragma指令

  我通常很不喜欢用#pragma指令或编译器属性。属性和#pragma指令一般是不可移植的,改变编译器可能会形成软件缺陷。然而,在调整嵌入式软件时,开发人员一般没有选择。使用属性和#pragma指令能够提升速度,并能根据实际状况有选择地优化某个功能。基于这些理由,想要优化软件的开发人员应该熟悉属性的使用,并且要阅读《用C语言编写可移植的优化程序》,这样他们才知道如何编写出可移植的最优程序,而且没有负面影响。

  技巧6—多作实验

  在优化系统方面没有一成不变的方法,开发人员不该该局限于任何一种特殊的技术。有时候学习和优化系统的最好方法是尝试各类实验并分析其结果。

  当我首次为了低功耗而优化系统时,作了不少实验,也出现了一些错误。经过实验过程和所记录的结果,我就可以理解什么有用,什么没用,以及作哪些事是在浪费资源和时间。如何最好地利用printf就是一个简单的例子: 经过尝试不一样的驱动模型能够发现,不少方法均可以显著提升开发人员使用printf时得到的实时性能,而人们设想的结果一般远好于真实结果。

  技巧7—深刻研究编译器产生的指令

  在资源特别有限的应用中,开发人员有时只需挽起袖子深刻理解编译器产生的指令。在将要执行的三四个广义指令间选择三元操做符而不是if/else是有区别的,这极可能会致使应用程序崩溃。

  虽然像C这样的语言是标准的,但每种编译器在优化和产生机器指令时有少量差别。惟一现实的方法是检查汇编语言,了解编译器在作什么。

  总结

  各类应用程序的不一样致使每种系统也是不一样的。但这些系统的优化基本也都离不开以上7个步骤。只要开发人员按照这个步骤走,能够说是离实现高效的系统优化又近了一步。

相关文章
相关标签/搜索