XCode 9.3 新的编译选项,优化 Swift 编译生成代码的尺寸

2018-02-27 11:07:29来源:https://swiftcafe.io/post/swift-optimization.md作者:Swift Cafe人点击

分享

XCode 9.3 新的编译选项,优化 Swift 编译生成代码的尺寸


swift 发布于 2018年02月23日


在 Swift 4.1 的编译器中,提供了一个新的优化选项。可以减少代码生成尺寸。 对生成的代码进行优化,是很多编译器都提供的功能,Swift 之前版本的编译器其实也提供了优化功能,如果你打开 XCode 项目的 Build Settings , 就可以找到一个叫做 Optimization Level 的选项,默认情况下,XCode 会对 Release 下的项目默认开启编译器优化:



这个选项在实际编译的时候,会给编译器传递一个 -O 参数,它就代表进行性能优化。


新增的编译选项


XCode 9.3,除了上述的性能优化之外,还提供了另外一个新的选项 -Osize , 对代码尺寸进行优化:



从上图中可以看到 -O 和 -Osize 两个参数是互斥的,只能选一个。 -O 前面我们说过了,是对代码的执行速度进行优化,但执行速度提升了,就会牺牲一部分代码空间。


反之 -Osize 是专门为节省代码空间这个目的而来的优化选项。 那么他们分别能带来多少收益和损失呢? 这点在 swift.org 的官方 Blog 也有介绍:



-Osize 根据项目不同,大致可以优化掉 5% - 30% 的代码空间占用。 相比 -0 来说,会损失大概 5% 的运行时性能。 如果你的项目对运行速度不是特别敏感,并且可以接受轻微的性能损失,那么 -Osize 就值得一用。


Single File 和 Whole Module


除了 -O 和 -Osize , 还有另外一个概念也值得说一下。 就是 Single File 和 Whole Module 。 在之前的 XCode 版本,这两个选项和 -O 是连在一起设置的,Xcode 9.3 中,将他们分离出来,可以独立设置:



Single File 和 Whole Module 这两个模式分别对应编译器以什么方式处理优化操作。


Single File 是逐个文件进行优化,它的好处是对于增量编译的项目来说,它可以减少编译时间,对没有更改的源文件,不用每次都重新编译。并且可以充分利用多核 CPU,并行优化多个文件,提高编译速度。


但它的缺点就是对于一些需要跨文件的优化操作,它没办法处理。如果某个文件被多次引用,那么对这些引用方文件进行优化的时候,会反复的重新处理这个被引用的文件,如果你项目中类似的交叉引用比较多,就会影响性能。


Whole Module 则是将项目所有的文件看做一个整体,不会产生 Single File 模式对同一个文件反复处理的问题,并且可以进行最大限度的优化,包括跨文件的优化操作。


缺点是,不能充分利用多核处理器的性能,并且对于增量编译,每次也都需要重新编译整个项目。


XCode 的默认设置使用的是 Whole Module 模式。 我特意搜索了一下,在 Stack Overflow 上面找到了一个比较好的总结,也给大家贴出来参考一下:




这篇帖子的地址是 https://stackoverflow.com/questions/47998583/whats-the-difference-between-single-file-optimization-vs-whole-module-optimizat 。


对于这个选项,我的理解是,如果没有特殊情况,使用默认的 Whole Module 优化即可。 它会牺牲部分编译性能,但的优化结果是最好的。


何为编译优化


关于编译优化,这话话题其实不小。 简单来说,现在我们用高级语言写出的代码,更大程度上是基于我们人的思维逻辑。 然后通过编译器,变成机器的逻辑。比如现在如果大家开发一个项目,更关注业务逻辑的实现,比如点击购买按钮,能不能正常调用下订单的函数。或者当用户完成某个功能,能不能按照预定的要求弹出评价提示等。


我们现在越来越少的会为怎么写一行代码能够减少电量消耗,或者如何提高多核 CPU 的利用率这类的问题花费精力。编译优化就是在一定程度上帮助我们处理这类问题的功能。


用 swift.org 中一篇 Blog 来举个例子:


struct X {


var x: Int { return 27 }


}


比如上面这个代码,定义了一个属性 x, 它通过一个函数返回一个整数 27。 如果你开启了编译优化,编译器就有可能将这个属性优化为 inline 函数(因为这个函数体相对简单)。所谓 inline 函数,就是在调用它的地方直接把它展开成代码。比如这样:


let ins = X()


print (ins.x)


上述代码实际在编译优化后,就成了这样:


let ins = X()


print( 27 )


那么这样替换能带来什么好处呢,因为在程序真正执行的时候,函数调用的开销要比直接执行某段代码大很多,所以将一些比较小的函数直接优化成 inline 的,就肯定会提高程序运行的效率了。


这就是编译优化的一个例子,上面说的 inline 替换是对性能进行优化,可想而知如果你的代码中多次调用了 ins.x 这个属性,那么他们就都会被替换,我们这个例子中这个函数体还比较简单,如果函数体稍微复杂一些,你的代码总量必然会被编译优化增大。 过多的 inline 虽然会对性能提升有帮助,但无疑会增大代码的尺寸。


这也是程序设计中守恒的一个定律,同样的条件下,空间和性能不可能兼得,需要取舍。


相信通过这个解释,大家应该更能理解 -O 和 -Osize 的区别了。 以官方 Blog 的解释, -O 更着重于优化性能,同时会带来代码空间的增大。 -Osize 着重于代码尺寸,比如官方 Blog 上面就有一点明确的说明, -Osize 对于 inline 函数的优化标准就比 -O 谨慎很多。 从这个角度看, inline 优化少了,代码尺寸自然会变小,同样的运行性能就会稍微降低。


当然,上面只是通过 inline 优化给大家举个例子,目的是帮助大家更好的理解编译优化的运作原理。 实际的编译优化操作,要远比我们这里描述的复杂。


总结


XCode 9.3 新增的 -Osize 编译选项,给大家提供了一个新的选择。 这篇文章也通过对它的介绍,给大家分享了关于编译优化知识的一些基本概念,也许会帮你在讨论问题的时候多一些谈资。同样,现在其实有不少项目对空间尺寸的优化需求在增多,我想这也是 -Osize 这个新的编译选项提供出来的原因之一吧。 如果你的项目恰好也有这方面的需求,不妨可以试一下它。


如果你觉得这篇文章有帮助,还可以关注微信公众号 swift-cafe,会有更多我的原创内容分享给你~

本站文章均为原创内容,如需转载请注明出处,谢谢。





关注微信公众号


发现更多精彩


swift-cafe




最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台