Xcode 4 - slow performance

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 2开发者_运维问答GHz 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.

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.

Next, delete project.xcworkspace.

Open Xcode and enjoy faster performance!

Thanks to: 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.

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

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

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 Info and checking Open in 32-bit mode.

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)

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

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.

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

Xcode 4 became extremely slow and kills my hard drive

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

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

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.

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:

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.

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.

You can avoid indexing Xcode. Doing so will improve memory performance of your system but will also prevent IDE features such as autocompletion and jump to definitions from working.

$ defaults write com.apple.dt.XCode IDEIndexDisable 1

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.

I finally got my Xcode to work normally by turning off the git feature.

I resolved my issue by disabling snapshots as described here:

Editing storyboard in Xcode 5 is very slow

In my case, it was the RAM usage.

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

I've found a trick to accelerate the compiling performance of XCode 4: When you run or compile or do any other processing in Xcode and it stalls open active monitor, select the Xcode process then click on the sample process. It will make the process unstuck and run again as normal which allow to build app in a reasonable time.