Xcode 4.3.2 and 100% CPU constantly in the idle time

Question

My Xcode started to behave very heavily from yesterday when working on medium size project (around 200 source files). Project compiles correctly and runs in both simulator and device. I do not use any 3rd party libraries, except few widely used includes (like JSON or facebook ios sdk).

It constantly uses CPU(s) at full speed, even if it is in idle state (no indexing, no compiling, no editing). The usage of RAM is relatively normal (300-50MB).

My machine uses: Core 2 Duo 3.04Ghz CPU, 8GB of RAM and Vertex OCZ 3 SSD drive.

I have tried every suggested solution found at stackoverflow:

1. Cleaned project
2. Cleaned Derived Data in Organizer
3. Cleaned repositories in Organizer
4. Cleaned xcodeproject bundle from workspace and userdata files as suggested here: https://stackoverflow.com/a/8165886/229229 (it is helping just for a moment and starts again after minute or so).
5. Restarted Xcode many times (with the same effect as in 4).
6. Disabled "Live issues"
7. even Reinstalled Xcode

Nothing helps. In most cases, Xcode indexes the project for a moment, then comes back to the normal performance, but after a while becomes unusable again. CPU jumps back to 95-100% for both cores, intelligence hangs, etc...

I am attaching screenshots of how the Xcode processes are seen by the Instruments:

UPDATE: After a moment of hope that I solved the problem by moving around few

#import "header.h"

statements from headers to the implementation files and exchanging them with forward declarations ... the problem came back again after a while. I am adding the console log. The strange thing is that the logs related to Xcode show up after I quit it, not during the run itsef.

Console logs:

5/11/12 9:27:03.777 AM [0x0-0x45045].com.apple.dt.Xcode: com.apple.dt.instruments.backgroundinstruments: Already loaded
5/11/12 9:27:05.571 AM Xcode: Performance: Please update this scripting addition to supply a value for ThreadSafe for each event handler: "/Library/ScriptingAdditions/SIMBL.osax"
5/11/12 9:27:58.168 AM Xcode: ERROR: Failed to create an alert for ID "enabled" based on defaults: 1

Answer 1

What stopped my nightmare was:

1. Change Always Search User Path to NO in Project build settings (bolded).
2. Remove -objC flag Other Linker Flags (also bolded setting).

And then delete Derived Data and wait until Xcode reindexes.

I am not sure which of them helped bacause I changed both of them at the same time and I am so behind my schedule I have no time to test it. I will improve this answer when I reproduce the bug and solution in spare time.

However, there is a hint: *Rethink and recheck your project / targets build settings.*

It is highly probable that this strange behavior may be caused by some unfortunate combination of build settings.

Answer 2

All my projects does this from time to time. I can shut down X-code and start it up again and it'll run fine for a while, then go back to using 200% CPU time (two cores fully loaded).

My solution is to use AppCode as my primary IDE (has the added benefit of being a much better IDE, but that's another story). I only start XCode when I need to edit storyboards and shut it down when I'm done - usually that keeps the problem at bay.

AppCode runs off the same project files/structure has better and faster indexing and never runs into this issue, so I can't see how this can be a settings/configuration problem - it must be a bug in XCode. Hence, I would not waste time changing your code structure as it will most likely only delay the problem, not fix it.

Answer 3

No way to know if the OP actually had a different root cause, but for me it appears to have been an Xcode glitch with git. Adding / committing my current changes solved my problem. Here is the complete scenario and what I did to get it fixed:

• Environment:
  • Xcode Version 5.1.1 (5B1008)
  • Macbook Pro OS X 10.9.2
  • 2 GHz Intel Core i7, 8GB RAM
• I noticed Xcode was starting to eat 200% of my CPU constantly.
• Not sure exactly when it started, but Xcode did freeze up on trying to make a snapshot (400% CPU usage for several minutes until I force-quitted Xcode)
• After reopening, I noticed Xcode was still stuck indefinitely at 200% CPU usage.
• Closing all projects did not work.
• Deleting all derived data and restarting did not work.
• Uninstalling Xcode and reinstalling at first held promise, but once I re-opened my main project, the CPU returned to a constant 200% CPU usage. (after indexing finished)
• Closing the troubled project did not help. Xcode was now stuck again in forever-kill-200%-of-CPU land.

After looking around Stack Overflow, multiple people alluded to git being an issue.

• I have a slightly complicated git repo (has a submodule repo and a subproject within the main Xcode project).
• I had pending changes in both the main repo and submodule portion of the repo.
• I closed Xcode and git added & committed all my current changes.
• Reopen Xcode and VIOLA! No more CPU being killed. Back down to 0.0% idle usage.

Xcode 5.1.x seems to struggle with git in other ways for me too (sometimes does not pick up changes in the GUI, etc.) so perhaps there are Xcode git integration bugs.

Answer 4

It looks like it's spending its time parsing ObjC included in the PCH.

• How many PCHs must clang generate? In your project, that would be one for C, one for ObjC, one for C++, one for ObjC++ for each dialect/lang used in your project and any dependent targets. That is -- if you have a dependent library included in your app's PCH and you are hacking on that library, all code sense in the app target must be invalidated and parsed again each time you alter a header included by your pch. And if your target compiles a C file, it will need a PCH for C. If it needs one for ObjC, it will need to generate one for ObjC.
• How often do you alter the PCH (or anything included by it)?
• Remove includes from the PCH. It's not unusual to see every linked framework included in a PCH (avoid doing this!).
• If you change your build or preprocessor settings, it may need to rebuild the code sense index for the target(s) entirely each time.
• Have you tried disabling live issues?