swift coredata 封装 swift module

转载

mob6454cc620c34 2023-09-23 11:07:10

文章标签 swift coredata 封装 swift 后端 xcode 编译器 文章分类 Swift 移动开发

本文讲的是Swift 3 语言中的全模块优化，

全模块优化是一种 Swift 编译器的优化模式。全模块优化的性能提升很大程度上因项目而异，可达到 2 倍甚至 5 倍的提升。

开启全模块优化可以使用 -whole-module-optimization （或者 -wmo）编译器标识，并且在 Xcode 8 中默认在新项目中被打开。另外 Swift 的包管理器在发布构建中使用全模块优化编译。

那么它是关于什么的？让我们先看看没有全模块优化编译器是如何工作的。

什么是模块和如何编译模块

一个模块是 Swift 文件的集合。每个模块编译成一个独立分布单元－框架（framework)或可执行程序。在单文件编译（没有 -wmo）中，Swift 编译器分别编译模块中的每一个文件。事实上，这就是背后发生的事情。作为一个使用者你不需要手动做这些。编译器驱动或者 Xcode 构建系统会自动完成。

在读取和解析一个源文件（并且完成其他工作，比如类型检查）之后，编译器开始优化 Swift 代码，生成机器码和写目标文件。最终，链接器链接所有目标文件并且生成共享库或者可执行文件。

在单文件编译中编译器的优化仅局限于单个文件。这限制了跨函数优化，比如调用和定义在同一文件中的函数内联或者泛型特殊化。

下面看一个例子。假设我们模块中的一个文件，名为 utils.swift，其中包含一个泛型的实用数据结构体 Container，其中含有一个方法 getElement

main.swift:

func add (c1: Container, c2: Container) -> Int {
  return c1.getElement() + c2.getElement()
}

utils.swift:

struct Container {
  var element: T

  func getElement() -> T {
    return element
  }
}

当编译器优化 main.swift 时，它并不知道 getElement 如何被实现。它只知道它是存在的。所以编译器生成了一个getElement即使简单的在 getElement 中返回声明，都需要在类型的元数据中查找来解决如何拷贝元素。它可以是一个简单的 Int，但它也可以是一个更大的类型，甚至涉及一些引用计数操作。这些编译器都不知道。

全模块优化

拥有全模块优化的编译器可以做的好很多。当使用 -wmo

这么做有两个巨大优势。首先，编译器了解模块中所有函数的实现，所以它能够执行诸如函数内联和函数特殊化等优化。函数特殊化是指编译器创建一个新版本的函数，这个函数通过一个特定的调用上下文来优化性能。例如，编译器能够针对各种具体类型对泛型函数进行特殊化处理。

在我们的例子中，编译器产生了一个使用具体类型 Int 来特殊化泛型 Container

struct Container {
  var element: Int

  func getElement() -> Int {
    return element
  }
}

然后编译器可以在 add 函数中内联已经特殊化的 getElement

func add (c1: Container, c2: Container) -> Int {
  return c1.element + c2.element
}

这个编译仅生成几个机器指令。对比单文件代码有很大的不同，单文件编译中会两次调用 getElement

跨文件的函数特殊化和函数内联仅是全模块优化的例子。如果编译器了解函数的实现，即使编译器决定不内联一个函数，它也有很大帮助。举例说，它能推出它的引用计数操作的行为。有了这个认识，编译器就能够在函数调用中删除冗余的引用计数操作。

全模块优化的第二大好处是，编译器能够推出所有非公有（non-public）函数的使用。非公有函数仅能在模块内部调用，所以编译器能够确定这些函数的所有引用。那么编译器可以用这个信息做什么？

一个非常基本的优化是消除所谓的「死」函数和方法。这些函数和方法是从未被调用和使用的。使用全模块优化，编译器知道一个非公有函数或方法是否根本没有被使用，如果是这种情况，那么编译器会除去它。为什么程序员会写一个从未被使用的函数？好吧，这不是死函数消除的最重要用例。常用函数变为死函数是其他优化的一个副作用。

我们假设 add 函数只在 Container.getElement 中被调用。在内联 getElement 之后，这个函数不在被使用，所以它可以被删除。即使编译器决定不内联 getElement，编译器也能删除原始 getElement 的泛型版本，因为 add

编译时间

单文件编译时，编译器驱动在不同的进程中开始编译每个文件，这能被并行地完成。此外，自从上次编译之后没有被修改的文件就不需要重新编译（假设所有依赖也没有修改）。这被称为增式编译。它节省了大量的编译时间，尤其是当你做了一个小改动的时候。在全模块编译中如何使这个成为可能？让我们来看看全模块优化模式更多的细节。

编译过程有多个阶段：分析程序，类型检查，SIL 优化，LLVM 后端。

大多数情况下，分析程序和类型检查是非常快的，并且我们希望它们在后续的 Swift 发行版中变得更快。SIL 优化程序（SIL 代表「Swift 中间语言」（Swift Intermediate Language））执行所有 Swift 特定的重要优化，例如泛型特殊化，函数内联等等。编译器的这个阶段通常需要大约三分之一的编译时间。大多数的编译时间花费在 LLVM 后端，它执行更底层的优化和生成代码。

执行全模块优化之后，在 SIL 优化程序中模块被分为多个部分。LLVM 后端使用多线程处理各个部分。如果这个部分自从上次构建以来未被修改，它也会避免重复处理。所以即使使用全模块优化，编译器也能够并行和增量地执行大型编译工作。