c编译时间优化

Ⅰ 提高c语言代码效率

C语言7种提高效率

1、位运算替代乘除

位运算是C语言中的最小数据单元，移位运算或位处理基本上是每个MCU或者处理器的指令集中直接支持的所以C代码编译成汇编以后基本上简单的几条汇编指令即可完成运算。

然而对于乘除法CPU一般无法直接运行，当然现在高端的芯片一般支持FPU等等之类的处理，相对而言速度得到了显着提升;但是大部分还是会比移位运算处理耗时，特别是有些编译器直接把乘除法编译成函数调用来处理。所以像n/8这样的处理直接使用n>>3即可替代，这样效率会更高。

2、变量的使用

使用全局变量相对局部变量效率更高，函数的局部变量一般处于函数内部，在调用过程中存在入栈与出栈野孝的情况，这样就增加了函数调用的耗时，而全局变量直接访问效率更高。当然全局变量是程序中要非常小心使用的，滥用全局变量的行为确实会增加系统各模块之间的耦合，所以在程席中要规范全局的统一接口使用。

同时对于变量类型的使用也是大家需要注意的，数据类型不是越大越好，比如uint64_t的处理汇编生成代码就相对比较多，执行效率一般比短数据类型要低，尽量选择芯片相同位数的数据类型处理，当然大部分更小的数据长度也是合适的。

3、指针替代数组

相对数组索引，指针运算效率更快，数组是一片连续的内存空间，那么通过指针移动进行数组数据的索引也是合适的。

比如我们遍历数组array[i]，任意一次的循环都需要对其进行下 “i”值的标记与计算，而当指针“p”位于array数组位置的时候，循环仅只需要对“p”进行增量的操作，这样指针耗时会比数组访问小很多。

4、算法优化

一些数据的处理明明可以通过更加简洁的算法，可是没脊侍大部分程序员非要以最傻瓜的方式进行运算，最容易理解的就是高斯求和，1~100累加，还是选择高斯求和算法，当然还有很多算法有多种形式，各有优劣，根据自身需求进行合理选择。特别是一些应用根本没有必要用使用高精度耗时的数据处理算法，选择一些低精度快速的算法更加合适。

5、优化分支语句

我们都知道if-else语句是最常用的分支语句，其特点就是逐一判断，既然是判断就会消耗时间，然而对于一些处理并不是每个分支都是均匀执行的，如果你把频繁执行的相应分支放到后面，势必就需要执行较多前面的逐一判断，从而降低代码执行效率。

所以我们要对各个分支的执行频率进行评估，把最有可能执行的放在判断语句前面执行。同样对于分支语句多级嵌套的情况，我们需要把频率性对较高的放到外层，频率低的放内层，这样减枯吵少不必要的外层判断。

6、循环语句的优化

在系统的多重循环过程中，需要程序员将最长的循环内容设置在系统的最内层，同时需要将最短的循环内容设置在系统的最外层。

这样，能够有效提升CPU的运行效率，减少循环次数。另外，如果在系统的循环过程中需要进行逻辑判断，且循环的次数相对较大，就需要将循环判断从系统内部转移到系统的外部。

7、无敌” 宏"的利用

宏在C语言中是灵活度非常高的语法特性，宏代码片段的使用其代码表现形式上与函数差异并不是很大，大伙有学习C++语言模板的经验，应该会觉得两者有颇多相似之处。

在对函数进行调用的过程中，需要通过栈对其进行储存，而且CPU在函数调用的过程中还要做好对数据的恢复准备，有效进行出栈和进栈的操作。所以占用CPU时间除了代码本身之外，对函数进行调用也需要占据一定的时间。而宏就能节省参数压栈、返回参数、C语言call调用以及执行return的操作步骤，从而提高程序的运行效率。

Ⅱ Xcode 构建速度优化（一）衡量编译时间

随着项目不断迭代，工程文件越来越多，引用的三方库也越来越多，这些直接导致编译时间的不断增加，完整编译一次项目动辄需要五分钟以上时间，实在有些影响开发效率，是时候来一波提速了。

为编译和构建提速，首先我们需要对速度有一个衡量标准：准确获得构建用时

首先，我们需要定义要衡量和优化的内容。 有两种选择：

xcode默认情况下会跟踪所有构建，我们可以通过更改xcode相关设置，来在活动查看器中显示出构建时间，通过命令行：

每次编译成功后，会在Successed之后显示出所用时间:

Xcode Build Timing Summary是Xcode10中加入的用于查看获取构建时间和发现用时瓶颈方面的最有利工具。 可以通过Proct->Perform Action->Build With Timing Summary来开启：这样在 Build Log 的末尾就会添加 Timing Summary Log。我们可以通过这个 log 看到哪个阶段是耗时的，便于我们进行优化。

如上图中: xib阶段的编译耗时明显是比普通c文件要多的，意味着我们可以通过减少xib方式来优化提升速度
而c文件的编译用时比总时间还要长，是因为c文件是并行编译的

在命令行中同样可以开启这个功能：

常用的第三方工具有 BuildTimeAnalyzer 、 xcode-build-times-rendering 、 XCLogParser 。

BuildTimeAnalyzer可以统计可以得出某个文件的类型检查时长，每个表达式的类型检查时长。

xcode-build-times-rendering是一个Ruby编写的第三方工具，可以方便地分别测量目标的构建时间并在图表上显示它们，使用gem安装

接下来使用这个工具自带命令配置项目

然后构建项目并生成报告：

这个工具使用上比较简单，缺点是只能从宏观上生成各个target编译的整体图标，无法详细列出各个内部编译明细

XCLogParser可以详细列出各个Target和内部每个文件的编译耗时，对我们分析编译时间瓶颈非常有帮助，它的工作原理主要是做为解析器，通过解析xcode编译生成的xcactivitylog日志来记录
安装：

编译项目后，进行安装

安装成功后通过命令：

会自动在当前目录的 build/xclogparser/reports/ 路径下生成报告，其中--project参数需要设置为待分析项目的名字，并注意当前在终端切换到希望写入日志的目录。

报告截图：

这个工具将作为我们后面分析提升编译构建速度的主要使用工具。

经过我多次在不同时间段，不同电脑上不断尝试编译，
我发现编译耗时是一个比较玄的东西，及时在同一台电脑，同一个项目， 同一套环境配置下，编译用时也会随着电脑当前状态（包括同时打开进程、散热等等）上下大幅跳动，就像算法时间复杂度一样，有时候我们明明做了一些细微的优化，但是结果反而是编译耗时增加了，这是很正常的事情
所以，衡量这个标准需要我们取多次试验中的平均值作为参考。