SourceKitService Consumes CPU and Grinds Xcode to a Halt
This is NOT a Beta issue. I am on Xcode 6.0.1, production release. The issue I am having is that when I try to do a Build or Run the code I am working on, Xcode becomes unresponsive for large periods of time and the SourceKitService consumes upwards of 400% of the CPU (according to Activity Monitor). This issue is new as of the last few days, although, oddly, I had been on Xcode 6.0 since it was officially released on Sept 17. I upgraded to 6.0.1 hoping it would contain a fix for this issue.
Any idea as to what the problem could be?
Answer
Ran into this problem with Xcode 6.1.1 earlier this afternoon (not beta, official released version). I had been running some code on Playground and was suspecting that to be the cause. CPU was pegged to nearly 100%, and Xcode was unable to complete builds.
So here's what I did:
1. Opened "Activity Monitor", which showed SourceKitService as the main CPU hog.
2. Within "Activity Monitor", double-clicked on the SourceKitService and clicked on "Open Files and Ports" section, which showed it was working on files under the /Users/myname/Library/Developer/Xcode/DerivedData/ModuleCache/ directory for a specific folder.
3. Deleted the specified folder (from a command-line, using rm -rf). The cache is regenerated based on Can I safely delete contents of Xcode Derived data folder? .
4. Using Activity Monitor again, Force-Quit SourceKitServer. Saw the now-all-too-familiar sign within Xcode saying that SourceKitService had crashed (so that's why SourceKitService sounded familiar!).
5. Repeated step 3.
The Mac is peaceful, again. No data was lost and Xcode didn't even have to be restarted (which I had tried unsuccessfully). Bottom line is that ModuleCache seems to be getting SourceKitService in a loop and deleting the folder seems to fix it. Hope this works for you too.
Bootnote:
By the way, the cause for SourceKitService issue was that I had too long an array declaration in my Swift class. I had over 200 entries in an array. Reduced it to 30 and the error went away. So the issue may have arisen due to some kind of stack overflow in apple code (pun intended).