编译 – 为什么Swift的编译时间这么慢？

概述我使用Xcode 6 Beta 6。 这是一个问题，我已经错过了一段时间，但它达到了一个点，现在勉强可用。 我的项目开始有一个体面的大小65 Swift文件和一些桥接的Objective-C文件(这真的不是问题的原因)。 它似乎像对任何Swift文件的任何轻微的修改(如在类中添加一个简单的空白，在应用程序中几乎不使用)将导致重新编译指定的目标的整个Swift文件。 经过深入调查，我发现编译器时间的 我使用Xcode 6 Beta 6。

这是一个问题，我已经错过了一段时间，但它达到了一个点，现在勉强可用。

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

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

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

我做了一些进一步的调查，如果我只保留应用程序委托与一个默认控制器编译是非常快，但随着我添加越来越多的我的项目文件，编译时间开始变得非常慢。

现在只有65个源文件，每次编译大约需要8/10秒。不是很迅速。

我没有看到任何帖子谈论这个问题，除了this one，但它是一个旧版本的Xcode 6.所以我想知道如果我是唯一的那种情况下。

更新

我已经检查了一些像Alamofire，Euler和CryptoSwift的GitHub的Swift项目，但没有一个有足够的Swift文件来进行比较。唯一的项目我发现，开始一个体面的大小是SwiftHN，即使它只有十几个源文件，我仍然能够验证同样的事情，一个简单的空间和整个项目需要重新编译，开始采取少时间(2/3秒)。

相比Objective-C代码，分析器和编译都很快，这真的感觉像Swift将永远不能处理大项目，但请告诉我错了。

更新与Xcode 6 Beta 7

仍然没有任何改善。这开始变得可笑。由于缺少#import在Swift，我真的不知道苹果将如何能够优化这。

更新与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的更改，这将是OK)，但也是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

这是已经有一段时间，因为我上次更新这个问题，所以这里是。

我们的应用程序现在约20k行几乎完全Swift代码，这是体面，但不突出。它进行了swift 2和swift 3迁移。它需要大约5 / 6m编译在2014年中期Macbook pro(2.5 GHz Intel Core i7)，这是一个干净的构建是好的。

然而，增量构建仍然是一个笑话，尽管苹果声称：

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

显然，我认为我们很多人只是笑了，检查出这个废话(添加一个私人(私人！)属性到我的项目的任何文件将重新编译整个事情…)

我想指出你们this thread在苹果开发者论坛，它有一些更多的信息关于这个问题(以及赞赏苹果开发沟通一段时间)

基本上人们已经想出了一些东西来尝试改进增量构建：

>将header_MAP_USES_VFS项目设置添加为true
>禁用从您的方案中查找隐式依赖项
>创建一个新项目并将您的文件层次结构移动到新的项目。

我会尝试解决方案3，但解决方案1/2没有为我们工作。

在这个整体情况下，讽刺的滑稽是，看看第一篇关于这个问题，我们使用Xcode 6，我相信swift 1或swift 1.1代码，当我们达到第一个编译迟缓，现在大约两年后，尽管实际改进从苹果情况与Xcode 6一样糟糕。多讽刺。

我真的很遗憾选择Swift over Obj / C为我们的项目，因为它涉及每天的沮丧。 (我甚至切换到AppCode，但这是另一个故事)

无论如何，我看到这篇文章有32k的意见和143 ups的写作，所以我想我不是唯一的。挂在那里的家伙尽管对这种情况悲观，可能有一些光在隧道尽头。

如果你有时间(和勇气！)我猜苹果欢迎雷达。

下一次！干杯

好吧，事实证明，Rob NAPIer是对的。它是一个单个文件(实际上是一种方法)，导致编译器去berzek。

现在不要误会我。 Swift每次都会重新编译所有文件，但是现在的伟大之处在于，Apple对其编译的文件添加了实时编译反馈，因此Xcode 6 GM现在可以显示正在编译的Swift文件以及实时编译的状态你可以看到在这个屏幕截图：

所以这很方便地知道你的文件是这么长时间。在我的case是这段代码：

var dic = super.Json().mutablecopy() as NSMutableDictionarydic.addEntrIEsFromDictionary([        "url" : self.url?.absoluteString ?? "","Title" : self.Title ?? ""        ])return dic.copy() as NSDictionary

因为属性标题的类型是var Title：String？而不是Nsstring。编译器在将其添加到NSMutableDictionary时会疯狂。

将其更改为：

var dic = super.Json().mutablecopy() as NSMutableDictionarydic.addEntrIEsFromDictionary([        "url" : self.url?.absoluteString ?? "","Title" : Nsstring(string: self.Title ?? "")        ])return dic.copy() as NSDictionary

使编译从10/15秒(也许更多)下降到一秒钟…惊人。

总结

以上是内存溢出为你收集整理的编译 – 为什么Swift的编译时间这么慢？全部内容，希望文章能够帮你解决编译 – 为什么Swift的编译时间这么慢？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。