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.

Parget

I did a fairly lengthy write-up for Xcode 4.2 in this post: stackoverflow.com/questions/7780663/… – Ciapas

I found a better solutions than all the ones explained here. I switched to AppCode. Yes, it was a $99, but it was cheaper than buying a new Mac. I have a MacBook Pro from 2010. It has a faster processor than any of the MacBook Airs, yet here in the office people using those can still get better speed. I've reinstalled Lion, then did a clean install for Mountain Lion, and still no luck. So now I use AppCode and I'm happy again. – Works

An unfortunate falsehood. AppCode is even slower than Xcode. It seems like a Java app. It totes a lot of fancy code completion, auto #import and so forth that require background processes. It might be better for some situations, but not for avoiding Xcode's slow performance. – Hurtle

Answer 1

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.

Redstone

deleting the workspace did help the problem, but i dont think you really need to get that applet heheh – Brubeck

Wow - I was tearing my hair out due to constant beach balling, and now it's running like a dream. Thanks for the absolutely essential tip. It's worth mentioning that it does temporarily reset your window layout (which may or may not be obvious), but it's a small price to pay. Also, if people want to manually remove the workspace file they can control-click on their xcodeproj file, choose 'show package contents', and then delete or move the .xcworkspace file. – Grimbald

@sudo Incredible, but now I've lost my performance excuse and can't buy myself a new, faster MBP!?! – Spoon

I'm having similar performance issues. One thing that I see in the small status pane in the top middle of the window is a message that says "Indexing | processed 0 of 1 file" (the numbers are just examples). Could that also be adding to the slow performance? – Middlebreaker

Yes that is definitely a cause for slowdowns. However, as long as your source files aren't too big, indexing should take very long. If it's still stuck on indexing, you should either try relaunching Xcode/computer and or try cleaning your build. – Redstone

I did this and it broke my project, everything refused to build and strange things started happening. – Raleighraley

@svth: That shouldn't be happening. This file just contains your window sizes and other user settings, and should not affect your project in any detrimental way. Perhaps something else is wrong with your project? Did you delete the right file? – Redstone

@sudorm-rf That's what I thought. So I tested this again. Basically, the app builds but can't be run in XCode. I get the following message: error: executable doesn't exist: '§<n¨å' warning: ignoring current working directory as it does not exist: /Development error: failed to launch '/Development/Platypus.app/Contents/MacOS/Platypus' warning: ignoring current working directory as it does not exist: /Development error: failed to launch '/Development/Platypus.app/Contents/MacOS/Platypus' – Raleighraley

@svth: I've never seen that error before. How strange! Have you tried posting on the developer forums? – Redstone

LOL, my project.xcworkspace was 1.2 MB huge! Now it's 6 KB... Once it gets bigger again, I'll reapply deletion remedy :) – Penitential

Somewhat helped. My workspace was only 96kB. It still hangs up for up to 10sec whenever I open MainwWindow.xib, other xibs are fast. – Predial

Probably because you have lots of windows & views contained in your main window file. I guess that's expected. – Redstone

I think the accepted answer (to delete .xcworkspace) is voted up for many folks didn't try the solution long enough to see the unexpected(bad) side effects. It might cause weird errors when you try to rename files, which is described in this post. And likely other unexpected errors too. So please be cautious before doing it. – Gabbard

Hey. The only objects inside the .xcworkspace file are 1) the interface state save file, and 2) a file listing the location of the project. So this should be perfectly safe to delete. Something odd could happen if Xcode was left open while the workspace was deleted, but really I doubt it could cause any harm. – Redstone

Thanks for laying out stuff inside .xcworkspace. Yes what happened is what happened. I can't recall whether Xcode was closed then. I will keep my eyes open next time I try the trick. – Gabbard

Plus, I don't see how you can deduce "it should be perfectly safe to delete" from .xcworkspace includes "1) the interface state save file, and 2) a file listing the location of the project". It looks not so obvious to me. – Gabbard

If you actually open up the .xcworkspace file, you can see it contains a file named contents.xcworkspacedata and a folder namedxcuserdata. This file contains a path for the saved state to relate back to the project itself. If you go into xcuserdata > name.xcuserdatad, you see a file named UserInterfaceState.xcuserstate. If you open this up in an editor, you can see that it only contains the editor sizes, I-beam points, selections, and other misc. oddities for various documents that have been opened in that project. This file can be safely removed with absolutely no consequences. – Redstone

If you look on most .gitignore files, you can see that this file is ignored (and thus not committed) with no consequences. – Redstone

This is BAD advice - the xcworkspace directory contains some of the core files for your project. On a very simple project, those files will be missing, and it will be fine, hence you probably didn't realise this yet. On complex projects - e.g. with shared Exectuables, shared Schemes, etc - you will corrupt your project. c.f. the .gitignore question for details of WHICH files inside xcworkspace are safe to delete - and which are not! stackoverflow.com/questions/49478/… – Admonish

It works, thank you! FYI: xcode v.4.6.3 running on mac book pro old model with 3 GB of ram. Before each character I typed in was pretty slow showing up, but now it normally shows up like a real text editor. – Botti

Answer 2

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

Pharmacy

oh man.. this one is really great. but IMPORTANT: this will erase your coredata from the simulator... you'll lose every testresult youve made so far. so thanks for a massively faster build, but the warning would have been nice =) – Sosthena

@benjamin83: That is one sweet tip! Xcode is rocking fast on my Mac Pro with 16GB RAM. I easily had 4GB to spare! I wish I could donate points to you for this. What an awesome tip. You need to blog about this. Thank you!! – Competition

for anyone doing this just be aware that THERE IS ONE THING YOU DO WANT TO KEEP in your derived data folder, your symbols file. Once you deploy an app, you will want to keep somewhere safe its symbol file in case you want to debug with a crash report – Liguria

@FranciscoGarcia If you deploy an app through the xcode organiser by archiving, the dSYMs wil be in the archive. This is stored outside of the derived data folder (at least it is on the current version of xcode - 4.6) – Ombre

how to auto mount the ramdisk? – Azide

@Azide You can use Automator to create a program that executes a script. In your system preferences go to User & Groups -> Login Items and add that program. I bet there's an easier way, but this one works – Pharmacy

you can just add an alias to your ~/.bash_profile such as alias ramdisk='diskutil erasevolume HFS+ "ramdisk" `hdiutil attach -nomount ram://8475854`' and then run a script early in your build phase ramdisk && ln -sF "${TARGET_BUILD_DIR}" /Volumes/ramdisk/ That'll make the ramdisk and symlink your build folder into it… no need to mess with any settings in Xcode. Great tip btw! – Vtol

The path ~/Library/Application\ Support/iPhone\ Simulator doesn't seem to be correct any longer. Please update. – Becker

Correct, Xcode 6 now stores the simulator data somewhere else. I'm going to update asap when I found out where the data goes now! – Pharmacy

Answer 3

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

Linettelineup

Answer 4

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.

Ideate

Didn't make any difference for me on my MBP 2.2Ghz i7 on 10.6.8. What computer/OS do you have? – Federalese

I have a Mac Mini with 2.26 Ghz Intel Core 2 Duo, 10.6.8, 2GB memory. – Ideate

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)

Admonish

Answer 6

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.

Gav

Answer 7

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

Peat

Answer 8

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.

Nephritis

Still slow for me on similar setup. (Xcode 4.1 and Mac OSX Lion on MacBook 2.26 GHz Intel Core 2 Duo, 2 GB RAM) – Dhahran

Answer 9

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.

Gravelblind

I got a brand new iMac Mid 2011, 3,1 i5, 12gb Ram + 1gb graphical memory, the issues don't disturb me very much on here, but before I purchased it I developed to on a MacBook, just get yourself an working machine, it's worth the money, trust me :) – Gravelblind

Answer 10

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.

Kacikacie

Answer 11

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.

Arabelle

Try renaming folder, /Applications/Xcode.app/Contents/PlugIns/IDESubversion.ideplugin, to something with a different ending. I have used a similar trick to disable the Git plugin. – Yeasty

Answer 12

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.

Agamic

Answer 13

In my case, it was the RAM usage.

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

Claudicant

Answer 14

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

Athwart

Answer 15

I resolved my issue by disabling snapshots as described here:

Editing storyboard in Xcode 5 is very slow

Jeraldjeraldine

Answer 16

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

Becker

Answer 17

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.

Tacho