Swift WHOLE_MODULE_OPTIMIZATION 改进了编译时间，但会导致 lldb/Xcode 崩溃

Swift WHOLE_MODULE_OPTIMIZATION improves compile time, but causes lldb/Xcode crash

提问by LunaCodeGirl

TL;DR

TL; 博士

Before

前

SWIFT_WHOLE_MODULE_OPTIMIZATION = NO

SWIFT_WHOLE_MODULE_OPTIMIZATION = NO

• Debug compile takes 10-15 minutes
• Release compile takes 25+ minutes
• poworks fine in LLDB

• 调试编译需要 10-15 分钟
• 发布编译需要 25 分钟以上
• po在 LLDB 中工作正常

After

后

SWIFT_WHOLE_MODULE_OPTIMIZATION = YES

SWIFT_WHOLE_MODULE_OPTIMIZATION = YES

• Debug compile takes 1-2 minutes
• Release compile takes ~8 minutes
• poalwayscauses Xcode to crash

• 调试编译需要 1-2 分钟
• 发布编译大约需要 8 分钟
• po总是导致 Xcode 崩溃

Any idea why the horrible compile times based on this info, and/or why Xcode might be crashing?

知道为什么基于此信息的可怕编译时间，和/或为什么 Xcode 可能会崩溃吗？

---

---

Deets

迪茨

I'm working on a large 100% Swift project (there are 3rd party libraries in Objective-C, but all our code is Swift). We have been having atrocious compile times, usually around 10-15 minutes to compile the debug configuration and 30+ minutes to compile the release configuration.

我正在处理一个 100% Swift 的大型项目（Objective-C 中有 3rd 方库，但我们所有的代码都是 Swift）。我们的编译时间很长，通常大约 10-15 分钟来编译调试配置，30 多分钟来编译发布配置。

This project has been very difficult to work with because of the horrible compile times. I've been searching for ways to improve this, particularly through build settings and for months had no luck. One thing I overlooked was SWIFT_WHOLE_MODULE_OPTIMIZATION, particularly because any mention of it claims it will increase a project's compile time.

由于可怕的编译时间，这个项目很难处理。我一直在寻找改善这一点的方法，特别是通过构建设置，几个月来一直没有运气。我忽略的一件事是SWIFT_WHOLE_MODULE_OPTIMIZATION，特别是因为任何提及它的人都声称它会增加项目的编译时间。

So the other day we enabled SWIFT_WHOLE_MODULE_OPTIMIZATIONand lo and behold we have a 10x improvement on compile times.

所以前几天我们启用了SWIFT_WHOLE_MODULE_OPTIMIZATION，瞧，我们的编译时间提高了 10 倍。

The problem is, now whenever we're debugging the project and try printing an object in lldb with po myObjectXcode immediately crashes. Here's some info from the crash log:

问题是，现在每当我们调试项目并尝试使用po myObjectXcode在 lldb 中打印对象时，都会立即崩溃。以下是崩溃日志中的一些信息：

Process: Xcode [5860]
Path: /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier: com.apple.dt.Xcode
Version: 6.4 (7720)
Build Info: IDEFrameworks-7720000000000000~8
App Item ID: 497799835
App External ID: 812725084
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Xcode [5860]

Date/Time: 2015-08-05 15:53:08.265 -0600
OS Version: Mac OS X 10.11 (15A235d)
Report Version: 11

Time Awake Since Boot: 13000 seconds

Crashed Thread: 20

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000008f
Exception Note: EXC_CORPSE_NOTIFY

VM Regions Near 0x8f: --> __TEXT 000000010ef62000-000000010ef63000 [ 4K] r-x/rwx SM=COW /Applications/Xcode.app/Contents/MacOS/Xcode

Application Specific Information:
ProductBuildVersion: 6E35b

进程：Xcode [5860]
路径：/Applications/Xcode.app/Contents/MacOS/Xcode
标识符：com.apple.dt.Xcode
版本：6.4 (7720)
构建信息：IDEFrameworks-7720000000000000~8
App 项目 ID：497799835
App External ID：812725084
代码类型：X86-64（本机）
父进程：??? [1]
负责人：Xcode [5860]

日期/时间：2015-08-05 15:53:08.265 -0600
操作系统版本：Mac OS X 10.11 (15A235d)
报告版本：11

启动后唤醒时间：13000 秒

崩溃的线程：20

异常类型：EXC_BAD_ACCESS (SIGSEGV)
异常代码：KERN_INVALID_ADDRESS at 0x000000000000008f
异常注意：EXC_CORPSE_NOTIFY

0x8f 附近的 VM 区域：--> __TEXT 000000010ef62000-000000010ef63000 [4K] rx/rwx SM=COW /Applications/Xcode.app/Contents/MacOS/Xcode

应用程序特定信息：
ProductBuildVersion：6E35b

Here's the stack trace on the crashed thread:

这是崩溃线程上的堆栈跟踪：

Thread 20 Crashed:: <DBGLLDBSessionThread (pid=6402)>
0   com.apple.LLDB.framework        0x0000000116b09ab4 swift::ArchetypeBuilder::resolveArchetype(swift::Type) + 68
1   com.apple.LLDB.framework        0x0000000116b0f808 std::__1::__function::__func<substConcreteTypesForDependentTypes(swift::ArchetypeBuilder&, swift::Type)::$_6, std::__1::allocator<substConcreteTypesForDependentTypes(swift::ArchetypeBuilder&, swift::Type)::$_6>, swift::Type (swift::Type)>::operator()(swift::Type&&) + 152
2   com.apple.LLDB.framework        0x0000000116bc0986 swift::Type::transform(std::__1::function<swift::Type (swift::Type)> const&) const + 54
3   com.apple.LLDB.framework        0x0000000116bc0f2b swift::Type::transform(std::__1::function<swift::Type (swift::Type)> const&) const + 1499
4   com.apple.LLDB.framework        0x0000000116bc0bbb swift::Type::transform(std::__1::function<swift::Type (swift::Type)> const&) const + 619
5   com.apple.LLDB.framework        0x0000000116bc0c0a swift::Type::transform(std::__1::function<swift::Type (swift::Type)> const&) const + 698
6   com.apple.LLDB.framework        0x0000000116b0c8f2 swift::ArchetypeBuilder::substDependentType(swift::Type) + 50
7   com.apple.LLDB.framework        0x0000000116e9554e (anonymous namespace)::LowerType::visitAnyStructType(swift::CanType, swift::StructDecl*) + 270
8   com.apple.LLDB.framework        0x0000000116e92e66 swift::Lowering::TypeConverter::getTypeLoweringForUncachedLoweredType(swift::Lowering::TypeConverter::TypeKey) + 150
9   com.apple.LLDB.framework        0x0000000116e92b39 swift::Lowering::TypeConverter::getTypeLowering(swift::Lowering::AbstractionPattern, swift::Type, unsigned int) + 2361
10  com.apple.LLDB.framework        0x0000000116f8f711 lldb_private::SwiftSILManipulator::emitLValueForVariable(swift::VarDecl*, lldb_private::SwiftExpressionParser::SILVariableInfo&) + 1521
11  com.apple.LLDB.framework        0x00000001172ac7ee (anonymous namespace)::LLDBNameLookup::emitLValueForVariable(swift::VarDecl*, swift::SILBuilder&) + 102
12  com.apple.LLDB.framework        0x0000000116ebb162 swift::Lowering::SILGenFunction::emitInitializationForVarDecl(swift::VarDecl*, swift::Type) + 98
13  com.apple.LLDB.framework        0x0000000116ebbc74 swift::ASTVisitor<(anonymous namespace)::InitializationForPattern, void, void, void, std::__1::unique_ptr<swift::Lowering::Initialization, std::__1::default_delete<swift::Lowering::Initialization> >, void, void>::visit(swift::Pattern*) + 404
14  com.apple.LLDB.framework        0x0000000116ebbc57 swift::ASTVisitor<(anonymous namespace)::InitializationForPattern, void, void, void, std::__1::unique_ptr<swift::Lowering::Initialization, std::__1::default_delete<swift::Lowering::Initialization> >, void, void>::visit(swift::Pattern*) + 375
15  com.apple.LLDB.framework        0x0000000116ebba0d swift::Lowering::SILGenFunction::visitPatternBindingDecl(swift::PatternBindingDecl*) + 45
16  com.apple.LLDB.framework        0x0000000116f0617c swift::Lowering::SILGenFunction::visitBraceStmt(swift::BraceStmt*) + 284
17  com.apple.LLDB.framework        0x0000000116ecd1c0 swift::Lowering::SILGenFunction::emitFunction(swift::FuncDecl*) + 320
18  com.apple.LLDB.framework        0x0000000116ea3966 swift::Lowering::SILGenModule::emitFunction(swift::FuncDecl*) + 246
19  com.apple.LLDB.framework        0x0000000116ea3828 swift::Lowering::SILGenModule::visitFuncDecl(swift::FuncDecl*) + 168
20  com.apple.LLDB.framework        0x0000000116ea579b swift::Lowering::SILGenModule::emitSourceFile(swift::SourceFile*, unsigned int) + 427
21  com.apple.LLDB.framework        0x0000000116ea5c22 swift::SILModule::constructSIL(swift::Module*, swift::SILOptions&, swift::SourceFile*, llvm::Optional<unsigned int>, bool, bool) + 386
22  com.apple.LLDB.framework        0x0000000116ea5d42 swift::performSILGeneration(swift::SourceFile&, swift::SILOptions&, llvm::Optional<unsigned int>, bool) + 98
23  com.apple.LLDB.framework        0x00000001172aa617 lldb_private::SwiftExpressionParser::Parse(lldb_private::Stream&, unsigned int, unsigned int, unsigned int) + 10715
24  com.apple.LLDB.framework        0x000000011706b3e8 lldb_private::ClangUserExpression::Parse(lldb_private::Stream&, lldb_private::ExecutionContext&, lldb_private::ExecutionPolicy, bool, unsigned int) + 1064
25  com.apple.LLDB.framework        0x000000011706cdb4 lldb_private::ClangUserExpression::Evaluate(lldb_private::ExecutionContext&, lldb_private::EvaluateExpressionOptions const&, char const*, char const*, lldb_private::SharingPtr<lldb_private::ValueObject>&, lldb_private::Error&, unsigned int, std::__1::shared_ptr<lldb_private::Module>*) + 628
26  com.apple.LLDB.framework        0x00000001171d1696 lldb_private::Target::EvaluateExpression(char const*, lldb_private::StackFrame*, lldb_private::SharingPtr<lldb_private::ValueObject>&, lldb_private::EvaluateExpressionOptions const&) + 376
27  com.apple.LLDB.framework        0x000000011716d75c lldb_private::SwiftLanguageRuntime::GetObjectDescription(lldb_private::Stream&, lldb_private::ValueObject&) + 668
28  com.apple.LLDB.framework        0x00000001170464e6 lldb_private::ValueObject::GetObjectDescription() + 370
29  com.apple.LLDB.framework        0x000000011548e228 lldb::SBValue::GetObjectDescription() + 76
30  com.apple.dt.dbg.DebuggerLLDB   0x00000001153f3c9e -[DBGLLDBDataValue _lldbValueObjectDescription] + 24
31  com.apple.dt.dbg.DebuggerLLDB   0x00000001153f3b7f -[DBGLLDBDataValue lldbDescription] + 29
32  com.apple.dt.dbg.DebuggerLLDB   0x00000001154023dc __87-[DBGLLDBSession printDescriptionOfDataValueToConsole:runAllThreads:completionHandler:]_block_invoke + 182
33  com.apple.dt.dbg.DebuggerLLDB   0x0000000115402e6d -[DBGLLDBSession handleNextActionWithState:withRunPending:] + 424
34  com.apple.dt.dbg.DebuggerLLDB   0x00000001153fdf44 DBGLLDBSessionThread(void*) + 980
35  libsystem_pthread.dylib         0x00007fff8ec12cb3 _pthread_body + 131
36  libsystem_pthread.dylib         0x00007fff8ec12c30 _pthread_start + 168
37  libsystem_pthread.dylib         0x00007fff8ec10419 thread_start + 13

Seems like we may be on the forefront of new technology here because I haven't found much help on this issue yet. I'm wondering if we have some sort of unusual configuration that is causing the compile time issues, or if there is a known reason why lldb might be crashing. Its the same on multiple different machines, with El Capitan, Yosemite, Xcode 6.3, Xcode 6.4. Any help is appreciated!

似乎我们可能处于新技术的最前沿，因为我还没有在这个问题上找到太多帮助。我想知道我们是否有某种不寻常的配置导致了编译时问题，或者是否存在导致 lldb 崩溃的已知原因。它在多台不同的机器上都是一样的，有 El Capitan、Yosemite、Xcode 6.3、Xcode 6.4。任何帮助表示赞赏！

采纳答案by Jiri Trecak

I've worked and I am actively working on projects that are probably even larger than yours (50+ libraries, hundreds of custom classes with thousands of LoC). It takes few seconds to compile and up to 2 minutes for release build (Late 2013 MBP), even for full Swift project.

我工作过并且正在积极从事可能比您的项目更大的项目（50 多个库、数百个具有数千个 LoC 的自定义类）。即使对于完整的 Swift 项目，编译也需要几秒钟，发布构建需要 2 分钟（2013 年末 MBP）。

I would highly recommend to look for other causes, as what this option tells you is that your problem is somewhere else since it affects app performance, not building speed. Maybe you have your .pch file full of stuff that does not belong there or something, it can cause this kind of slowing.

我强烈建议寻找其他原因，因为此选项告诉您问题出在其他地方，因为它会影响应用程序性能，而不是构建速度。也许您的 .pch 文件中充满了不属于那里的东西或其他东西，它会导致这种速度变慢。

Other interesting thing is use of inference. I personally declare type for every single variable just because it is easier to read for others, but there is more to it. Since the inference can get complicated, it can cause compiler to take A LOT of time to figure out what your code actually does. Read this example article, though it was more like alpha-problem. BUT MAYBE, just maybe, you have something like this in your code as well. What would be worth doing is trying to remove all the swift code, compile libraries if that works well, then you know the problem is in your swift code and it will be probably connected to this.

另一个有趣的事情是推理的使用。我个人为每个变量声明类型只是因为其他人更容易阅读，但还有更多。由于推理可能会变得复杂，因此可能会导致编译器花费大量时间来弄清楚您的代码实际做了什么。阅读这篇示例文章，虽然它更像是阿尔法问题。但也许，只是也许，您的代码中也有类似的内容。值得做的是尝试删除所有 swift 代码，如果运行良好，则编译库，然后您就知道问题出在您的 swift 代码中，并且可能与此相关。

Also, if you provide WHAT actually slows your build time (because you can see whole build process with timestamps, and there is high probability that one step will just take forever), it can help pinpoint the problem more accurately.

此外，如果您提供 WHAT 实际上会减慢您的构建时间（因为您可以看到带有时间戳的整个构建过程，并且一个步骤很可能会永远持续下去），它可以帮助更准确地查明问题。

Hope it helps!

希望能帮助到你！

Edit: Another articleon this interested topic

编辑：关于这个感兴趣话题的另一篇文章

回答by Jo?o Nunes

I managed to fix this in our project. (12 mins total compile time)

我设法在我们的项目中解决了这个问题。（总编译时间 12 分钟）

The key is to set the SWIFT_WHOLE_MODULE_OPTIMIZATION = YESas you say in the user definedsettings

关键是SWIFT_WHOLE_MODULE_OPTIMIZATION = YES按照你说的user defined设置

But you need to do one more change. You need to set the optimization level to Nonein debug otherwise you will not be able to debug your app.

但是您还需要再做一项更改。您需要将优化级别设置为Nonein debug，否则您将无法调试您的应用程序。

I wrote a blog post about it here:

我在这里写了一篇关于它的博客文章：

https://tech.zalando.com/blog/improving-swift-compilation-times-from-12-to-2-minutes/

https://tech.zalando.com/blog/improving-swift-compilation-times-from-12-to-2-minutes/