为什么 xcodebuild 和 Xcode 4.2 这么慢？

发布于 2024-12-10 06:34:56 字数 490 浏览 6 评论 0原文

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

瞳孔里扚悲伤 2024-12-17 06:34:56

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

恢复到 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++。翻译越复杂，解析和编译源代码所需的时间就越长，尤其是当您的依赖性很高时。如果您可以轻松地在依赖项中设置语言障碍，请这样做。
您可以通过defaults禁用代码感知索引（也减少了内存需求）。

硬盘

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

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

构建

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

文件错误

（不言自明）

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

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.

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.

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

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:

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 uses a new (more accurate) completion parser.

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

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.

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.

File Bugs

(self explanatory)

回复收藏 0 原文

为你拒绝所有暧昧 2024-12-17 06:34:56

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

回复收藏 0 原文