事实证明罗伯·纳皮尔是对的。这是一个文件(实际上是一个方法)，导致编译器去berzek。

别误会我的意思。Swift每次都会重新编译你所有的文件，但现在最棒的事情是，苹果在它编译的文件上添加了实时编译反馈，所以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

因为属性标题类型是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秒(甚至更多)下降到一秒…很神奇的。

因为所有这些东西都是测试版，而且Swift编译器(至少到今天为止)还没有打开，我猜你的问题没有真正的答案。

首先，比较Objective-C和Swift编译器有点残酷。Swift仍处于测试阶段，我相信苹果正在努力提供功能和修复错误，而不仅仅是提供闪电般的速度(你不会从购买家具开始盖房子)。我猜苹果会在适当的时候优化编译器。

如果出于某种原因，所有源文件都必须完整编译，那么可以选择创建独立的模块/库。但是这个选项还不可行，因为Swift在语言稳定之前不允许使用库。

我猜他们会优化编译器。由于同样的原因，我们不能创建预编译模块，很可能编译器需要从头编译所有内容。但是一旦语言达到稳定的版本，二进制文件的格式不再改变，我们将能够创建我们的库，也许(?)编译器也将能够优化它的工作。

不过，这只是猜测，因为只有苹果知道……

这可能与项目的规模无关。它可能是一段特定的代码，甚至可能只有一行。您可以通过尝试一次编译一个文件而不是整个项目来测试这一点。或者试着查看构建日志，看看哪个文件花了这么长时间。

这段38行的要点代码在beta7中要花一分钟多的时间来编译，这是可能导致麻烦的代码的一个例子。所有这些都是由这一个块引起的:

let pipeResult =
seq |> filter~~ { $0 % 2 == 0 }
  |> sorted~~ { $1 < $0 }
  |> map~~ { $0.description }
  |> joinedWithCommas

只需将其简化一两行，它几乎可以立即编译。问题是这会导致编译器中的指数增长(可能是阶乘增长)。显然，这并不理想，如果你可以隔离这种情况，你应该打开雷达来帮助清理这些问题。

编译器花费大量时间推断和检查类型。因此，添加类型注释对编译器有很大帮助。

如果你有很多链式函数调用，比如

let sum = [1,2,3].map({String($0)}).flatMap({Float($0)}).reduce(0, combine: +)

然后，编译器需要一段时间来找出应该是什么类型的和。添加类型会有所帮助。还有一个有用的方法是将间歇步骤放入单独的变量中。

let numbers: [Int] = [1,2,3]
let strings: [String] = sum.map({String($0)})
let floats: [Float] = strings.flatMap({Float($0)})
let sum: Float = floats.reduce(0, combine: +)

特别是对于数字类型CGFloat, Int，它可以帮助很多。像2这样的文字数字可以表示许多不同的数字类型。所以编译器需要从上下文中找出它是哪一个。

也应该避免使用像+这样需要花费大量时间查找的函数。使用几个+来连接几个数组很慢，因为编译器需要找出每个+应该调用哪个+的实现。因此，如果可能的话，使用变量a: [Foo]和append()代替。

你可以添加一个警告来检测在Xcode中哪些函数编译缓慢。

在目标的构建设置中搜索其他Swift标志并添加

-Xfrontend -warn-long-function-bodies = 100

对编译时间超过100毫秒的每个函数发出警告。

需要注意的一点是，Swift类型推断引擎在使用嵌套类型时可能非常缓慢。你可以通过观察各个编译单元的构建日志来大致了解导致缓慢的原因，这些编译单元花费了很长时间，然后将完整的xcode衍生命令复制并粘贴到终端窗口中，然后按CTRL-\以获得一些诊断。查看http://blog.impathic.com/post/99647568844/debugging-slow-swift-compile-times以获得完整的示例。

在我的情况下，Xcode 7没有任何不同。我有多个函数需要几秒钟来编译。

例子

// Build time: 5238.3ms
return CGSize(width: size.width + (rightView?.bounds.width ?? 0) + (leftView?.bounds.width ?? 0) + 22, height: bounds.height)

在打开可选项之后，构建时间下降了99.4%。

// Build time: 32.4ms
var padding: CGFloat = 22
if let rightView = rightView {
    padding += rightView.bounds.width
}

if let leftView = leftView {
    padding += leftView.bounds.width
}
return CGSizeMake(size.width + padding, bounds.height)

在这篇文章和这篇文章中可以看到更多的例子。

Xcode的构建时间分析器

我开发了一个Xcode插件，对于遇到这些问题的人来说可能会派上用场。

Swift 3似乎会有改进，所以希望我们能看到我们的Swift代码编译得更快。