为什么 xcodebuild 和 Xcode 4.2 这么慢？答案

【问题标题】：Why are xcodebuild and Xcode 4.2 so slow?为什么 xcodebuild 和 Xcode 4.2 这么慢？
【发布时间】：2011-12-08 12:03:09
【问题描述】：

我在一个相对较大的项目（几万行代码）上使用 Xcode 4.2，而且速度非常慢。编辑没问题，但是每当我尝试编译项目（在 Xcode 中，或在命令行中使用 xcodebuild）时，我的机器（四核 i7 MacBook Pro，4 GB RAM）都会停止运行。我注意到，在启动 xcodebuild 后，它直接产生了 8 个以上的 clang 进程，而没有启动“真正的”编译进程。到目前为止，在 stout 上没有看到 xcodebuild 输出。我试过reducing the number of parallel build processes，但一开始还是启动了很多clang进程。该项目使用 6 或 7 个直接依赖的外部项目，并且可能有 120 个源文件。在 Xcode 3.2 下，该项目过去编译得非常快。发生了什么？以及如何让 Xcode 再次变得更快？

【问题讨论】：

fwiw，这在 4.2 中并不新鲜。最后一个主要的硬件平台是 Xc4.0。

标签： xcode xcode4 build xcode4.2 xcodebuild

【解决方案1】：

另一个缓慢的罪魁祸首是插件。 Subversions 插件绝对扼杀我的 Xcode 性能。我跟着the instructions in this SO post 禁用它。哇！

【讨论】：

【解决方案2】：

关于“投入更多硬件”方法的快速说明..

总结：我经历了一次重大硬件升级后速度的小幅提升

测试：在克隆的 macbook 上构建/运行完全相同的项目（唯一的区别应该是它们的硬件）

旧款 Macbook Air（1.86GHZ Core 2 Duo 只有 2GB RAM）
对比
全新 Macbook Pro（2.3GHZ Core i7 8GB RAM）

在 IPHONE 3GS 上构建
Macbook Air 1:00 - 1:15
Macbook Pro ~1:00

=> 0 到 0:15 的速度增加

在 IPHONE 4S 上构建
Macbook Pro ~0:35
Macbook Air ~0:50

=> ~15 秒的速度提升

**部分测试：两台机器之间的 SIMULATOR 构建时间确实存在显着差异

【讨论】：

MBA 中的 SSD 可能有助于缩小性能差距。我注意到通过在我的 Mac 上投入更多的 RAM，性能得到了巨大的提升，这些 Mac 都有传统的硬盘。

【解决方案3】：

您可以在 XCode Preferences 中打开分布式构建，并找到一些友好的人，通过与您形成编译机集群来帮助您构建您的应用程序。

有趣的是，即使他不在，与之前的问题相比，你的编译器仍然使用不同的算法/机制来以惊人的速度构建你的应用程序；）

所以，这意味着他们在 Apple 已经忘记了不团队工作的孤独程序员，因此孤独的编译场景纯粹在 4.0 - 4.2 版本中进行测试

【讨论】：

【解决方案4】：

我们大多数人都有三个主要选择：

恢复到 Xcode 3 进行日常开发。
投入更多硬件。
更改项目结构并应用大规模开发技巧（即使 20-30 KSLOC 并不大）。

最简单的解决方案是恢复到 Xc3。是的，Xc4 比 Xc3 需要很多个；内存、CPU、磁盘空间和 I/O。您必须确定最大的问题在哪里，以减少它对您的影响。

我最近买了一个新的 MBP，物理内核翻倍，物理内存翻倍，同时升级到 Lion 和升级 Xc4。编译时间确实有所改善，但其余大部分时间实际上更慢，而且更耗费资源。这根本不是人们对 IDE 的期望，它也不允许多个打开的项目并且还使用统一的工作区视图。

迁移到 Lion + Xc4 后，我在以下所有类别中的硬件需求增加了一倍多：

内存

对于大多数使用 Xc4 和 Lion 的重要项目来说，4GB 现在太少了。你仍然可以减少这个。我的 2 台机器上有 8GB 和 10GB，Xc4 很容易用完它们（但我的项目比你的更复杂，除非你写了很长的行）。无论如何，您可以通过以下方式减少此问题：

购买更多内存。
如果您在 Xcode 中构建大型项目，请禁用索引。这可以减半 Xcode 的内存消耗。
以 32 位运行 Xcode。这不是每个人都可以选择的，因为在大型项目中它会超过 4 GB。
减少构建过程的数量（再次）。
经常重新启动 Xcode（它本身并不能很好地清理）。
使用 clang 作为编译器。 Clang 实例通常比 Apple 的 GCC 4.2 使用更少的内存。
卸载不经常更改的依赖目标。示例：在大多数情况下，您不需要每天重建第三方库。

CPU

Xcode 4 使用新的（更准确的）完成解析器。

减少包含依赖关系图和依赖关系。使用 Obj-C 很容易做到这一点，因为每个 Obj-C 实例都是一个指针。示例：从标题中删除松散依赖的框架包含。
正确分离依赖项和模块。开发库，但尽量使它们相当小，并注意它们将添加的依赖项。示例：我领导一个项目，其中开发人员添加了一个小功能（不到应用程序的 1%），但由于它需要的依赖项数量（例如 Three20 和更多），最终可执行文件的二进制大小翻了一番（构建时间增加了，解析器还有很多工作要做）。该功能不需要其中大部分内容 - 它们只是无法被剥离，因为它们是 objc 符号。
尽可能减少翻译次数。
优化您使用前缀标头的方式。您可以共享它们，也可以无缘无故地创建它们。这对编译器的好处多于 IDE。
尽量减少内存使用。 GC 工作（包括所有 NSObject 分配）在大型项目中消耗了超过 1/3 的 CPU 使用率，但当它的堆很大时它仍然花费大量时间收集。
使用外部文本编辑器和 VC 客户端。很明显，因为 Xc4 在大型项目中经常显示 SBBOD。
尽量减少语言复杂性。按复杂度排列：C、ObjC、C++、ObjC++。翻译越复杂，解析和编译源代码所需的时间就越长，尤其是当您的依赖关系很高时。如果您可以轻松地在依赖项中设置语言障碍，请这样做。
您可以disable code sense indexing via defaults（也可以减少内存需求）。

硬盘

这可以是速度/大小的平衡。

购买速度更快的（例如 SSD）。
清理并最小化您的标头依赖项。
使用 RAM 磁盘，例如 Make RAM Disk。
购买更多内存。随着 Xc4 的消耗量，它最终会在大型项目中经常换出到磁盘。
优化您的构建以正确使用 pch 文件。这并不总是显而易见的方向：我已经有好几年没有在大型项目中使用它们了。
清除 Xcode 和 Instruments 留下的临时文件 they can be huge。在某些情况下，您可以将它们保存在自定义位置。如果它们确实消耗了数十 GB 并且您的构建目录与您的引导目录相同，那么您可以通过定期清理它们来减少磁盘的工作量。

构建

在 Xc4 中，与 Xcode 并行的 xcodebuild 现在加倍工作（默认情况下单独的构建目录）。在 Xc3 中，默认是构建到相同的目标。验证您的设置 - 如果您允许，Xcode 将执行大量冗余构建（例如，每个工作区/配置一个目标，而不是 Xc3 的平面构建模型）。
或者只是在抽屉里装满四核 MacMini，然后将其用作专用或分布式构建器。

文件错误

（不言自明）

【讨论】：

谢谢。很好的解决方案可能性集合。
另一条评论：我将我的机器分别升级到了 8 GB 和 12 GB RAM。这也有助于加快速度。我猜 Xcode 4 非常非常耗内存。
@Arne 写这篇文章后，我意识到禁用索引可以将 Xcode 在 huuuge 项目中的内存消耗减半。
@justin：很好的答案！我注意到导入确实对自动完成速度有显着影响。

【解决方案5】：

另一种可能的解决方案，在某些情况下可能有助于加速 Xcode 4：就我而言，主要问题似乎是我的 build/ 文件夹中的四个文件意外地被我的 git 存储库签入。在编译期间，Xcode 注意到构建文件夹发生了变化，并触发了 git。由于在我的情况下构建文件夹包含数千个文件，因此性能下降了。从 git 中完全删除 build/ 文件夹（无论如何都不应该签入）大大减少了编译时间和系统负载。性能仍然比 Xcode 3 慢，但比以前好很多。

【讨论】：