为什么 xcodebuild 和 Xcode 4.2 这么慢? [英] Why are xcodebuild and Xcode 4.2 so slow?

问题描述

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

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?

推荐答案

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

Most of us have three primary options:

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

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

The easiest solution is revert to Xc3. Yes, Xc4 requires a lot more 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.

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

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 did improve, 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.

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

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

内存

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

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:

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

• Buying more memory.
• Disable indexing if you are building out huge projects in Xcode. This can halve Xcode'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.

CPU

Xcode 4 使用新的(更准确)完成解析器.

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

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

硬盘

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

This can be a speed/size balance.

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

• 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.

构建

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

• 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).

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

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

文件错误

(不言自明)

这篇关于为什么 xcodebuild 和 Xcode 4.2 这么慢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！