为什么 xcodebuild 和 Xcode 4.2 这么慢？

Why are xcodebuild and Xcode 4.2 so slow?

提问by Arne

I am using Xcode 4.2 on a relatively large project (a few ten thousand lines of code) and it is horribly slow. Editing is ok, but whenever I try to compile the project (in Xcode, or with xcodebuild on the command line), my machine (quad core i7 MacBook Pro, 4 GB RAM) crawls to a halt. I have noticed that directly after starting xcodebuild, it spawns more than 8 clang processes, without the "real" compile processes starting. No xcodebuild output is so far seen on stout. I've tried reducing the number of parallel build processes, but still lots of clang processes are launched at the beginning. The project uses 6 or 7 direct dependent external projects and has maybe 120 source files. Under Xcode 3.2 the project used to be compiled very quickly. What's happening? And how can I make Xcode fast again?

我在一个相对较大的项目（几万行代码）上使用 Xcode 4.2，它非常慢。编辑没问题，但是每当我尝试编译项目时（在 Xcode 中，或在命令行上使用 xcodebuild），我的机器（四核 i7 MacBook Pro，4 GB RAM）都会爬行停止。我注意到，在启动 xcodebuild 后，它直接产生了 8 个以上的 clang 进程，而没有启动“真正的”编译进程。到目前为止，在 Stout 上没有看到 xcodebuild 输出。我已经尝试减少并行构建进程的数量，但仍然有很多 clang 进程在开始时启动。该项目使用 6 或 7 个直接依赖的外部项目，可能有 120 个源文件。在 Xcode 3.2 下，该项目过去编译得非常快。发生了什么？我怎样才能让 Xcode 再次变快？

回答by justin

Most of us have three primary options:

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

• Revert to Xcode 3 for daily development.
• Throw more hardware at it.
• Change your projects' structures and apply large scale development tricks (even though 20-30 KSLOC is not large).

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

The easiest solution is revert to Xc3. Yes, Xc4 requires a lotmore than Xc3; memory, CPU, and disk space and I/O. You will have to determine where your biggest problems are to reduce the amount it affects you.

最简单的解决方案是恢复到 Xc3。是的，XC4需要大量超过XC3; 内存、CPU、磁盘空间和 I/O。您必须确定您最大的问题在哪里，以减少它对您的影响。

I recently bought a new MBP with twice the physical cores and twice the physical memory, upgraded to Lion and upgraded Xc4 at the same time. The compilation times didimprove, but much of the rest is actually slower, and far more resource hungry. That's not at all what one would expect from an IDE which also disallows multiple open projects and also uses a unified workspace view.

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

The move to Lion + Xc4 more than doubled my hardware demands in all of the following categories:

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

Memory

记忆

4GB is now too little for most nontrivial projects using Xc4 and Lion. You can still reduce this. I have 8GB and 10GB on my main 2 machines, Xc4 consumes it all quite easily (but my projects are more complex than yours, unless you write reeaeaaaally long lines). Anyways, You can reduce this problem by:

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

• Buying more memory.
• Disable indexing if you are building out huge projects in Xcode. This can halveXcode's memory consumption.
• Running Xcode in 32 bit. This is not an option for everyone, because it will exceed 4 GB in larger projects.
• Reduce the number of build processes (again).
• Restarting Xcode often (It doesn't do a very good job cleaning up after itself).
• Use clang as your compiler. Clang instances in general use less memory than Apple's GCC 4.2.
• Offload dependent targets which do not change often. Example: You will not need to rebuild third party libraries daily in most cases.

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

CPU

中央处理器

Xcode 4 uses a new (more accurate) completion parser.

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

• Pare down your include dependency graphs, and dependencies. This is quite easy to with Obj-C, since every Obj-C instance is a pointer. Example: remove loosely dependent framework includes from your headers.
• Separate your dependencies and modules properly. Develop libraries, but try to make them fairly small and be aware of the dependencies they will add. Example: I lead a project where a dev added a small feature (less than 1% of the app), but due to the number of dependencies it required (e.g. Three20 and then a few more), the binary size of the final executable doubled (and the build times went up, and the parser had a lot more work to do). Most of this was not needed for the feature - they just could not be stripped because they were objc symbols.
• Reduce translation counts, if possible.
• Optimize how you use prefix headers. You can share them, and you can create them for no good reason. This benefits the compiler more than the IDE.
• Minimize memory usage. GC work (including all NSObject allocs) consumes over 1/3 of the CPU usage in larger projects, but it still spends a lot of time collecting when its heap is huge.
• Use external text editors and VC clients. Pretty obvious because Xc4 displays the SBBOD rather often in large projects.
• Minimize language complexity. In order of complexity: C, ObjC, C++, ObjC++. The more complex the translations, the longer it will take to parse and compile your sources, especially when your dependencies are high. If you can easily set up language barriers in your dependencies, do so.
• You can disable code sense indexing via defaults(also reduces memory demands).

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

Hard Disk

硬盘

This can be a speed/size balance.

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

• Buy a faster one (e.g. SSD).
• Cleanup and minimize your header dependencies.
• Use a RAM Disk, such as Make RAM Disk.
• Buy more memory. With the amount Xc4 consumes, it ends up swapping out to disk often in large projects.
• Optimize your builds to use pch files appropriately. This is not always the obvious direction: I have not used them for several years in large projects.
• Clear out the temp files Xcode and Instruments leave behind, they can be huge. In some cases, you can save them in customized locations. If they do consume tens of GB and your build dir is the same as your boot dir, then you will make your disk work a lot less by cleaning them up regularly.

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

Builds

构建

• In Xc4, xcodebuild parallel to Xcode now doubles the work (separate build dirs by default). In Xc3, the default was to build to the same destination. Verify your settings - Xcode will do a ton of redundant building, if you allow it (e.g. one target per workspace/config, rather than Xc3's flat build model).

• Or just fill a drawer with quad core MacMinis and use that as a dedicated or distributed builder.

• 在 Xc4 中，与 Xcode 并行的 xcodebuild 现在使工作翻倍（默认情况下单独的构建目录）。在 Xc3 中，默认是构建到相同的目的地。验证您的设置 - 如果您允许，Xcode 将进行大量冗余构建（例如，每个工作区/配置一个目标，而不是 Xc3 的平面构建模型）。

• 或者只是用四核 MacMini 装满一个抽屉，然后将其用作专用或分布式构建器。

File Bugs

文件错误

(self explanatory)

（不言自明）

回答by Arne

One more possible solution that in some cases might help speed up Xcode 4: In my case, the main problem seems to have been that accidentally four files from my build/ folder had been checked in with my git repository. During compilation Xcode notices that the build folder changed, and triggers git. Since the build folder contains thousands of files in my case, the performance went down. Removing the build/ folder completely from git (shouldn't have been checked in anyway) reduced the compilation times and system load massively. Performance is still slower than with Xcode 3, but much better than before.

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

回答by Sandijs

You can switch on Distributed Building in XCode Preferences, and find some friendly person who will help you build your app by forming compilation machines cluster with you.

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

The funny thing is that even he is off, your compiler still uses different algorithm/mechanism to build you app in a blazing speed if compared to the problems before ;)

有趣的是，即使他不在，与之前的问题相比，您的编译器仍然使用不同的算法/机制以极快的速度构建您的应用程序 ;)

So, that means that they at Apple have forgotten about lonely programmers who don't work in teams and therefore lonely compilation scenario is purely tested in versions 4.0 - 4.2

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

回答by user353877

Quick Note Regarding 'Throw more hardware at it' approach..

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

SUMMARY: I experienced a SMALL speed increase from making a SIGNIFICANT hardware upgrade

总结：我进行了一次重大的硬件升级，速度略有提高

Test: Build/Run the exact same project on cloned macbooks (where the only difference should be their hardware)

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

Old Macbook Air (1.86GHZ Core 2 Duo ONLY 2GB RAM)
vs
Brand New Macbook Pro (2.3GHZ Core i7 8GB RAM)

旧 Macbook Air（1.86GHZ Core 2 Duo 仅 2GB RAM）
与
全新 Macbook Pro（2.3GHZ Core i7 8GB RAM）

BUILDING ON IPHONE 3GS
Macbook Air 1:00 - 1:15
Macbook Pro ~1:00

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

=> 0 to 0:15 of speed increase

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

BUILDING ON IPHONE 4S
Macbook Pro ~0:35
Macbook Air ~0:50

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

=> ~15 seconds of speed increase

**Partially tested: There DOES apear to a significant difference between build times for the SIMULATOR between the 2 machines

=> ~15 秒的速度增加

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

回答by Ben Flynn

Another culprit for slowness is plugins. The Subversions plugin was absolutely killingmy Xcode performance. I followed the instructions in this SO postto disable it. WHEW!

另一个缓慢的罪魁祸首是插件。Subversions 插件绝对扼杀了我的 Xcode 性能。我按照this SO post中的说明禁用它。哇！