Xcode 4 - slow performance

Question

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.

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.

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

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.

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

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.

Answer 1

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

---

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

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

Then you tell Xcode to store derived data there

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 6:

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

Older Xcode versions:

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!!!

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

Answer 2

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.

Answer 3

I've tried just about everything that was suggested in this thread and [numerous] others and the only thing that worked for me was to "disable" subversion for the project. Here's the crappy part -- the ONLY way I could "disable" the built-in SVN plugin was to frig my /etc/hosts file with a bogus IP address, effectively causing all SVN access to fail.

I tried removing/renaming the IDESubversion.ideplugin in /Developer/Library/Xcode/PrivatePlugIns, but Xcode 4.2.1 pukes and refuses to start.

I tried removing my SVN repositories from Xcode each and every time I restart Xcode, but Xcode crashes within a few minutes.

I tried turning off "Remote Status" via File->Source Control->Hide Remote Status (did nothing for me).

Now that I've set my SVN hostname to 1.2.3.4 in my hosts file, Xcode works great and doesn't show the SBBOD almost every time I switch between files.

$ grep 1.2.3.4 /etc/hosts
1.2.3.4 svn.myhost.com

Then, when I really want to do version control, I have to un-frig the hosts file and use cmd line svn.

Answer 4

If you have slow performance while modifying a .xib file with the interface builder / editor, then go under File Inspector for the .xib and disable auto-layout. Make your edits to the .xib, then as a final step, re-enable auto-layout and add or adjust constraints.

Answer 5

Xcode 4.2, 4.3:

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

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

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.

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

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

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

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.

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

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

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.

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)

Answer 6

In my case, it was the RAM usage.

Try to kill a few Chrome tabs or rarely used apps.