swift - 为什么 Swift 编译时间这么慢？

Question

我正在使用 Xcode 6 Beta 6。

这件事已经困扰我一段时间了，但现在已经到了几乎无法使用的地步。

我的项目开始有 65 个 Swift 文件和一些桥接的 Objective-C 文件(这实际上不是问题的原因)的体面大小。

似乎对任何 Swift 文件的任何轻微修改(例如在应用程序中几乎不使用的类中添加一个简单的空格)都会导致指定目标的整个 Swift 文件被重新编译。

经过更深入的调查，我发现几乎 100% 的编译器时间是 CompileSwift Xcode 运行 swiftc 的阶段命令在目标的所有 Swift 文件上。

我做了一些进一步的调查，如果我只使用默认 Controller 保留应用程序委托(delegate)，编译速度会非常快，但是随着我添加越来越多的项目文件，编译时间开始变得非常缓慢。

现在只有 65 个源文件，每次编译大约需要 8/10 秒。一点也不快。

除了 this one，我还没有看到任何帖子讨论过这个问题。 ，但它是旧版本的 Xcode 6。所以我想知道在这种情况下是否只有我一个人。

更新

我在 GitHub 上检查了一些 Swift 项目喜欢 Alamofire , Euler和 CryptoSwift ，但他们都没有足够的 Swift 文件来进行实际比较。我发现的唯一一个规模合适的项目是 SwiftHN ，即使它只有十几个源文件，我仍然能够验证同样的事情，一个简单的空间和整个项目需要重新编译，这开始需要一点时间(2/3 秒)。

与分析器和编译都非常快的 Objective-C 代码相比，这真的感觉 Swift 永远无法处理大项目，但请告诉我我错了。

使用 Xcode 6 Beta 7 更新

仍然没有任何改善。这开始变得荒谬了。与缺#import在 Swift 中，我真的不知道 Apple 将如何优化这一点。

使用 Xcode 6.3 和 Swift 1.2 更新

苹果已添加 incremental builds (以及许多其他编译器优化)。您必须将代码迁移到 Swift 1.2 才能看到这些好处，但 Apple 在 Xcode 6.3 中添加了一个工具来帮助您这样做:



然而

不要像我一样高兴得太快。他们用来使构建增量的图解算器还没有得到很好的优化。

首先，它不考虑函数签名的变化，所以如果你在一个方法的块中添加一个空格，所有依赖于该类的文件都将被重新编译。

其次，它似乎基于重新编译的文件创建树，即使更改不会影响它们。例如，如果将这三个类移动到不同的文件中

class FileA: NSObject {
    var foo:String?
}
class FileB: NSObject {
    var bar:FileA?
}
class FileC: NSObject {
    var baz:FileB?
}

现在如果你修改 FileA ，编译器会明显标记 FileA要重新编译。它还会重新编译 FileB (根据对 FileA 的更改就可以了)， 但是 还有 FileC因为 FileB被重新编译，这很糟糕，因为 FileC从不使用 FileA这里。

所以我希望他们改进依赖树求解器...我已经打开了一个 radar使用此示例代码。

使用 Xcode 7 beta 5 和 Swift 2.0 更新

昨天苹果发布了 beta 5，在发行说明中我们可以看到:

Swift Language & Compiler • Incremental builds: changing just the body of a function should no longer cause dependent files to be rebuilt. (15352929)

我已经试过了，我必须说它现在工作得很好(真的!)。他们极大地优化了 swift 的增量构建。

我强烈建议您创建一个 swift2.0使用 XCode 7 beta 5 分支并保持你的代码是最新的。你会对编译器的增强感到高兴(但是我会说 XCode 7 的全局状态仍然很慢且有问题)

使用 Xcode 8.2 更新

自从我上次更新这个问题以来已经有一段时间了，所以就在这里。

我们的应用程序现在大约有 2 万行几乎完全是 Swift 代码，虽然不错但并不出色。它经历了 swift 2 和 swift 3 迁移。在 2014 年年中的 Macbook pro(2.5 GHz Intel Core i7)上编译大约需要 5/6m，这在干净的构建上是可以的。

然而，尽管 Apple 声称:

Xcode will not rebuild an entire target when only small changes have occurred. (28892475)

显然，我认为我们中的许多人在看完这些废话后都笑了(向我的项目的任何文件添加一个私有(private)(私有(private)!)属性将重新编译整个事情......)

我想指出你们 this thread在 Apple 开发者论坛上，其中包含有关该问题的更多信息(以及不时感谢 Apple 开发人员就此事进行交流)

基本上人们已经提出了一些尝试改进增量构建的方法:

添加 HEADER_MAP_USES_VFS项目设置设置为 true

禁用 Find implicit dependencies来自您的计划

创建一个新项目并将您的文件层次结构移动到新的层次结构。

我将尝试解决方案 3，但解决方案 1/2 对我们不起作用。

在整个情况下具有讽刺意味的是，在查看有关此问题的第一篇文章时，我们使用的是 Xcode 6 和 swift 1 或 swift 1.1 代码，当我们达到第一次编译迟缓时，现在大约两年后，尽管 Apple 进行了实际改进情况和 Xcode 6 一样糟糕。多么讽刺。

我其实 真后悔为我们的项目选择 Swift 而不是 Obj/C，因为它涉及日常的挫折。 (我什至切换到 AppCode，但那是另一回事)

无论如何，我看到这篇 SO 帖子在撰写本文时有 32k+ 次浏览和 143 次提升，所以我想我不是唯一一个。尽管对这种情况持悲观态度，但仍然坚持下去，隧道尽头可能会有一些曙光。

如果你有时间(和勇气!)，我猜苹果会欢迎这方面的雷达。

下次再来!干杯

使用 Xcode 9 更新

偶然发现 this今天。 Xcode 悄悄地引入了一个新的构建系统来改善当前糟糕的性能。您必须通过工作区设置启用它。



已经试过了，但会在完成后更新这篇文章。不过看起来很有希望。

Answer 1

好吧，事实证明罗伯·纳皮尔是对的。是一个单一的文件(实际上是一种方法)导致编译器崩溃。

现在不要误会我的意思。 Swift 每次都会重新编译您的所有文件，但现在最棒的是，Apple 为其编译的文件添加了实时编译反馈，因此 Xcode 6 GM 现在可以实时显示正在编译的 Swift 文件以及编译状态正如您在此屏幕截图中看到的:



因此，了解您的哪个文件花费了这么长时间非常方便。就我而言，这是一段代码:

var dic = super.json().mutableCopy() as NSMutableDictionary
dic.addEntriesFromDictionary([
        "url" : self.url?.absoluteString ?? "",
        "title" : self.title ?? ""
        ])

return dic.copy() as NSDictionary

因为属性(property) title类型为 var title:String?而不是 NSString .将它添加到 NSMutableDictionary 时，编译器疯了.

将其更改为:

var dic = super.json().mutableCopy() as NSMutableDictionary
dic.addEntriesFromDictionary([
        "url" : self.url?.absoluteString ?? "",
        "title" : NSString(string: self.title ?? "")
        ])

return dic.copy() as NSDictionary

使编译从 10/15 秒(甚至更多)减少到一秒......太棒了。