Xcode 4 - 性能缓慢

Xcode 4 - slow performance

提问by Kzrbill

I have an issue with Xcode 4 really responding very slowly to user interactions, e.g. editing code, scrolling areas etc. This particularly happens with larger scale projects with many controllers/view files etc.

我有一个问题，Xcode 4 对用户交互的响应真的很慢，例如编辑代码、滚动区域等。这尤其发生在具有许多控制器/视图文件等的大型项目中。

I completely wiped the hard disk and re-installed Snow Leopard and Xcode the other week but steadily it ground to a frustrating response time again (over a number of days) disrupting workflow considerably.

前一周我完全擦除了硬盘并重新安装了 Snow Leopard 和 Xcode，但它再次稳定地导致令人沮丧的响应时间（超过数天），严重扰乱了工作流程。

I have also on occasion removed the project's "derived data" via the Organiser -> Projects and this has had little effect.

我有时也通过 Organizer -> Projects 删除了项目的“派生数据”，但这几乎没有影响。

I'm wondering if there is anything I can do to improve performance other than get a higher specced machine in the first instance.

我想知道除了首先获得更高规格的机器之外，我是否可以采取任何措施来提高性能。

FYI I'm running MacBook with Intel Core 2 Duo processors at 2GHz and 4GB of RAM.

仅供参考，我正在运行配备 Intel Core 2 Duo 处理器、2GHz 和 4GB RAM 的 MacBook。

In case we need to upgrade I'd also like to know if people are experiencing this poor performance from Xcode 4 on well specced machines (which would make our hardware upgrade rather pointless as it's only Xcode that has any performance issue on the MacBook).

如果我们需要升级，我还想知道人们是否在配置良好的机器上遇到 Xcode 4 这种糟糕的性能（这将使我们的硬件升级变得毫无意义，因为只有 Xcode 在 MacBook 上有任何性能问题）。

If anybody has any suggestions or recommendations or could even let us know how improved hardware effects Xcode's performance on larger project trees then that would be extremely helpful and also a valuable resource for other devs in a similar position.

如果有人有任何建议或建议，或者甚至可以让我们知道改进的硬件如何影响 Xcode 在更大的项目树上的性能，那么这将是非常有帮助的，也是处于类似位置的其他开发人员的宝贵资源。

回答by sudo rm -rf

If you purge the workspace file it helps speed it up.

如果您清除工作区文件，它有助于加快速度。

First, make sure Xcode isn't open. Now find your project file. Right-click on it, and select Show Package Contents.

首先，确保 Xcode 未打开。现在找到您的项目文件。右键单击它，然后选择Show Package Contents。

Next, delete project.xcworkspace.

接下来，删除project.xcworkspace。

Open Xcode and enjoy faster performance!

打开Xcode，享受更快的性能！

Thanks to: http://meachware.blogspot.com/2011/06/speed-up-xcode-4.html

感谢：http: //meachware.blogspot.com/2011/06/speed-up-xcode-4.html

---

---

Edit: I've gotten several comments about this noting that for some projects this might cause problems. Make sure you have a backup of your project before performing these steps, and don't forget to check and test your project afterwards. Be sure you still have all of your executables and schemes.

编辑：我收到了几条评论，指出对于某些项目，这可能会导致问题。在执行这些步骤之前，请确保您有项目的备份，并且不要忘记在之后检查和测试您的项目。确保您仍然拥有所有可执行文件和方案。

回答by benjamin.ludwig

IMPORTANT UPDATE: Paths changed for Xcode 6 (Thanks for the comment dcc)! I just added the alternative way.

重要更新：Xcode 6 的路径已更改（感谢 dcc 的评论）！我只是添加了另一种方式。

---

---

There is another nice trick to fasten up builds by creating a ram disk with the following line of code:

通过使用以下代码行创建 ram 磁盘，还有另一个不错的技巧可以加快构建速度：

diskutil erasevolume HFS+ "ramdisk" `hdiutil attach -nomount ram://8475854`

This creates an in-memory disk image with a size of about 4 GB. But be careful, you need to have enough memory. Of course you can create a smaller image like 2 GB (that would be 4237927).

这将创建一个大小约为 4 GB 的内存磁盘映像。但是要小心，你需要有足够的内存。当然，您可以创建一个更小的图像，如 2 GB（即 4237927）。

Then you tell Xcode to store derived data there

然后告诉 Xcode 将派生数据存储在那里

You cannot tell Xcode to store the iPhone Simulator data there directly, but you can create a folder on the ramdisk and create a symbolic link instead of the iPhone Simulator directory by doing this:

您不能告诉 Xcode 将 iPhone Simulator 数据直接存储在那里，但您可以通过执行以下操作在 ramdisk 上创建一个文件夹并创建符号链接而不是 iPhone Simulator 目录：

Xcode 6:

代码 6：

cd /Volumes/ramdisk
mkdir CoreSimulator
rm -R ~/Library/Developer/CoreSimulator
ln -s /Volumes/ramdisk/CoreSimulator ~/Library/Developer/CoreSimulator

Older Xcode versions:

较旧的 Xcode 版本：

cd /Volumes/ramdisk
mkdir iPhone\ Simulator
rm -R ~/Library/Application\ Support/iPhone\ Simulator
ln -s /Volumes/ramdisk/iPhone\ Simulator ~/Library/Application\ Support/iPhone\ Simulator

If I build for the simulator with this setup, it's up and running in no time :)

如果我使用此设置为模拟器构建，它会立即启动并运行 :)

Be aware that the ram disk will disappear when you restart your machine, so it could be a good idea to create a script or something that runs on startup. AND DON'T PLACE ANY DATA THERE THAT YOU WANT TO KEEP!!!

请注意，当您重新启动机器时，ram 磁盘将消失，因此创建脚本或在启动时运行的内容可能是个好主意。并且不要在那里放置任何您想保留的数据！！！

UPDATE 2013-03-12:

更新 2013-03-12：

1. Read the comment from Francisco Garcia below!

2. With my new MBP (containing a SSD drive) I do not need this method any more. Xcode runs like hell :). I hope this is not seen as advertising for the big fruit concern, it's just an experience report...

1. 阅读下面弗朗西斯科·加西亚的评论！

2. 使用我的新 MBP（包含 SSD 驱动器），我不再需要这种方法。Xcode 运行得像地狱:)。我希望这不是大果关注的广告，这只是一个经验报告......

回答by greg

Disabling Live Issues in General Preferences has made a definite difference. I also setup a scheme without gdb enabled for situations where I'm frequently re-running (no gdb speeds up launch quite a bit).

在常规首选项中禁用实时问题产生了明显的不同。我还为我经常重新运行的情况设置了一个没有启用 gdb 的方案（没有 gdb 可以大大加快启动速度）。

回答by gyozo kudor

For me, Xcode gained a huge performance increase after setting it to run in 32-bit mode (it was 64 by default). It is almost as fast as the old Xcode 3. You can switch to 32 bit by right-clicking the app (in /Developer/Applications/XCode.app) and selecting Get Infoand checking Open in 32-bit mode.

对我来说，Xcode 在设置为以 32 位模式运行后获得了巨大的性能提升（默认为 64）。它几乎与旧的 Xcode 3 一样快。您可以通过右键单击应用程序（在/Developer/Applications/XCode.app 中）并选择获取信息并选中 以 32 位模式打开来切换到 32 位。

回答by Adam

Xcode 4.2, 4.3:

Xcode 4.2、4.3：

Major problems with the file-indexer (same code that runs Spotlight, which has been buggy for years? Probably).

文件索引器的主要问题（运行 Spotlight 的相同代码，多年来一直有问题？可能）。

Disable everything non-essential that is involved with "watching" files:

禁用与“观看”文件有关的所有非必要内容：

1. Quick Help (NB: never click on the QH tab! Even hiding the Assistant still causes the code to run! Switch to a different tab before moving to a new file...)
2. SCM management (SVN, Git, etc - Xcode's git support is still a little buggy (can corrupt projects), and they've dropped SVN support, so you shouldn't be using it anyway!)
3. try deleting your workspace folder (as per accepted answer), but only if its large on disk
4. ...anything else you can find related to status of individual files

1. 快速帮助（注意：永远不要点击 QH 选项卡！即使隐藏助手仍然会导致代码运行！在移动到新文件之前切换到不同的选项卡......）
2. SCM 管理（SVN、Git 等 - Xcode 的 git 支持仍然有一些问题（可能会损坏项目），而且他们已经放弃了 SVN 支持，所以无论如何你都不应该使用它！）
3. 尝试删除您的工作区文件夹（根据接受的答案），但前提是它在磁盘上很大
4. ...您可以找到的与单个文件状态相关的任何其他信息

Xcode 4.4, 4.5:

Xcode 4.4、4.5：

These versions have a major mem leak, a broken file indexer (but better than 4.2 and 4.3), and maybe a private swap file problem.

这些版本有一个主要的内存泄漏、一个损坏的文件索引器（但比 4.2 和 4.3 好），并且可能存在私有交换文件问题。

Eventually, by disabling/enabling swap space ( how to disable or enable swapping in mac os x) , and using normal hard drives on several machines, and by running experiments on machines with 2 GB RAM up to 16 GB RAM, I found that Xcode seems to run its own swap-space, independent of the OS X swap (!).

最终，通过禁用/启用交换空间（如何在 mac os x 中禁用或启用交换），并在多台机器上使用普通硬盘驱动器，并通过在 2 GB RAM 到 16 GB RAM 的机器上运行实验，我发现 Xcode似乎运行自己的交换空间，独立于 OS X 交换（！）。

(this might be a mistake - maybe there's an extra form of OS X swapping I dont know about - but the system swap files didn't get larger or smaller, while disk space jumped by gigabytes up and down on some machines)

（这可能是一个错误 - 也许有一种我不知道的额外形式的 OS X 交换 - 但系统交换文件没有变大或变小，而磁盘空间在某些机器上上下跳跃了千兆字节）

Observed:

观察到的：

1. Xcode 4.4/4.5 will randomly take all the RAM in your system (10's of GB for a tiny project) so that the rest of the system grinds to a halt, stuck waiting for disk swapping

   1. WORSE: on macbooks with SSD's, you won't know this has happened
   2. WORST: ...even though it's possibly damaging your hard disk (SSD's don't like thrashing writes)

2. Xcode will hog access to the hard-disk so it can do its (broken) internal file indexing. When system memory gets low, and OS X needs to do swapping ... it gets stuck waiting for Xcode to index files ... and Xcode takes more memory while it waits ... and: BOOM! on smaller systems, OS X eventually hangs

3. Xcode does not need OS X swap space

1. Xcode 4.4/4.5 将随机占用您系统中的所有 RAM（一个小项目需要 10 GB），以便系统的其余部分停止，卡在等待磁盘交换

   1. 更糟糕的是：在带有 SSD 的 macbook 上，你不会知道这已经发生了
   2. 最糟糕的：...即使它可能会损坏您的硬盘（SSD 不喜欢颠簸写入）

2. Xcode 将占用对硬盘的访问权限，因此它可以执行其（损坏的）内部文件索引。当系统内存变低时，OS X 需要进行交换......它会卡在等待 Xcode 索引文件......并且 Xcode 在等待时占用更多内存......并且：BOOM！在较小的系统上，OS X 最终会挂起

3. Xcode 不需要 OS X 交换空间

The last one is very interesting. If you have a lot of memory (e.g. 16 GB), try disabling swap space permanently. Xcode runs faster, because OS X Lion has some bugs in the mem management where it swaps even when it doesn't need to.

最后一个非常有趣。如果您有大量内存（例如 16 GB），请尝试永久禁用交换空间。Xcode 运行得更快，因为 OS X Lion 在内存管理中存在一些错误，即使它不需要，它也会交换。

If xcode slows suddenly, it's swapping internally, at which point you can just kill and restart it.

如果 xcode 突然变慢，它会在内部交换，此时您可以杀死并重新启动它。

(if you have an SSD, the only way you can know if its started swapping is to wait for it to "get slower". Otherwise, you know as soon as you hear the HD thrash: there's no system swapfile any more, so the only possible cause is Xcode)

（如果你有一个 SSD，你可以知道它是否开始交换的唯一方法是等待它“变慢”。否则，你一听到 HD 抖动就知道：不再有系统交换文件，所以唯一可能的原因是 Xcode）

You can safely disable swap even if you have 2GB RAM (I had only one OS X crash per month when I tried this, ran it this way for a year), but it will stop you doing high-end video / graphics work with files that need multi-gigabytes just to run. Feel free to try it for a few weeks and see what happens.

即使您有 2GB RAM，您也可以安全地禁用交换（我尝试此操作时每月只有一次 OS X 崩溃，以这种方式运行一年），但它会阻止您对文件进行高端视频/图形工作需要数千兆字节才能运行。随意尝试几周，看看会发生什么。

But ... restarting Xcode whenever it slows down works wonders. On machines with less RAM, Xcode's private swapfile seems to get IMMEDIATELY deleted when you close down (doesn't seem to happen on machines with lots of RAM)

但是......每当它变慢时重新启动Xcode会产生奇迹。在 RAM 较少的机器上，当您关闭时，Xcode 的私有交换文件似乎会被立即删除（在有大量 RAM 的机器上似乎不会发生）

回答by Dick

None of these responses really improved performance in my case (over time Xcode 4.1 became hardly usable, only quitting it now and then helped).

在我的情况下，这些响应都没有真正提高性能（随着时间的推移，Xcode 4.1 变得几乎不可用，只是偶尔退出它才有帮助）。

However, I just found out that if I keep closing all my documents (control-command-W) it seems to stay fast. Xcode automatically keeps all the documents that you click on in memory somehow, and you can navigate between them with control-command left/right arrow. If you accidentally open too many (especially IB windows), it crawls to a halt. Just closing all open docs now and then seems to alleviate this without the need to do a full restart.

但是，我刚刚发现，如果我一直关闭所有文档（control-command-W），它似乎会保持快速。Xcode 以某种方式自动将您单击的所有文档保存在内存中，您可以使用控制命令向左/向右箭头在它们之间导航。如果您不小心打开太多（尤其是 IB 窗口），它会爬行停止。不时关闭所有打开的文档似乎可以缓解这种情况，而无需完全重新启动。

回答by kris

The following post by @lukasz helped a bit, particularly his item #8 in his answer (Closed Utility Panel and Quick Help Pane)

@lukasz 的以下帖子有所帮助，尤其是他的答案中的第 8 项（已关闭实用程序面板和快速帮助面板）

Xcode 4 became extremely slow and kills my hard drive

Xcode 4 变得非常慢并且杀死了我的硬盘

回答by Ricardo Sanchez-Saez

Everybody experiencing these issues should try Xcode 4.1 on Mac OS X Lion. I am surprised how muchfaster and responsive it is on the same hardware (Macbook Pro 2.66 GHz Core 2 Duo with 4GB of RAM here).

遇到这些问题的每个人都应该在 Mac OS X Lion 上尝试 Xcode 4.1。我惊奇地发现多少它是在相同的硬件更快，响应（MacBook Pro的2.66 GHz的Core 2 Duo处理器与4GB的RAM在这里）。

I suppose they fixed tons of performance bugs with this release.

我想他们在这个版本中修复了大量的性能错误。

回答by quellish

Fire up Instruments with the time profile template and attach it to the running Xcode (or clang, llvm, etc. if your problem is during builds). You should be able to see the problem pretty quickly. I have seen very different causes on different machines. Version control is often a culprit.

使用时间配置文件模板启动 Instruments 并将其附加到正在运行的 Xcode（或 clang、llvm 等，如果您的问题是在构建期间）。您应该能够很快看到问题。我在不同的机器上看到了非常不同的原因。版本控制通常是罪魁祸首。

回答by Tim Specht

I'm facing the same issues. They were partly fixed since the beta builds are still persistent. It seems that Xcode internally got one or more leaks which are floating your memory. You can watch this nifty "feature" very well when using the integrated Interface-Builder. Two possible solutions beneath praying and filling bug-reports to apple:

我面临同样的问题。由于 beta 版本仍然存在，因此它们已部分修复。Xcode 内部似乎有一个或多个泄漏，这些泄漏使您的内存浮动。使用集成的 Interface-Builder 时，您可以很好地观看这个漂亮的“功能”。向苹果祈祷和填写错误报告的两种可能的解决方案：

1. Don't use internal Builder, launch the external application instead.
2. Quit Xcode from time to time, this should free the memory which was leaked.

1. 不要使用内部构建器，而是启动外部应用程序。
2. 不时退出 Xcode，这应该会释放泄漏的内存。