Xcode 7 CPU 100%

Hi,

Same problem here, on a mid-2012 Macbook Pro, Xcode tends to consume 100% CPU (and eats my battery at the same time). I have to Force Quit and restart again.

Does it happen every time for you ? Or only when you have no wifi ?

I have exact same problem:

MacBook Pro Retina 15 inch mid 2014 running Yosemite.

XCode 7.0 (7A220)

I too have this issue. Is there no way to esclate this?

i think when you first launch any new install of xcode 7+, it installs other unknown tools. i usually kill it then on second opening, all is good.

Same thing here. Happens at randome times... just freezes up the UI. Very frustrating.

Exact same probleme here.

Yes, I had this problem too. But my problem has been solved after I upgrade OS X to El Capitan. This problem gone.

But having new problem instead but not 100%++ CPU.

There's not enough information in this conversation for anyone to guess at what you're running into - if you're even all running into the same issue. Please grab CPU samples / spindumps when you're running into this issue, and file bug reports. If you echo your bug report ids here, we might be able to offer some comments / suggestions. Thanks!

Same here, xCode keep running 150% ~ 180% all the time, no-stop, and I just start the xCode without open anything/project

It sems working normally after reboot

I am experiencing this issue right now on Mac OS Sierra with XCode 8.2.1. My Mac has 16GB of RAM, but XCode is using 300% of my CPU. Is there any fix for this?

Yes, same here. I'm on Xcode 8.2.1 (2016 Macbook Pro) and everything will be fine for awhile, then for no reason I can identify, CPU goes through the roof and my battery life gets murdered... Super annoying.

I'm also noticing that it indexes basically all the time (after every save, for example).

[EDIT: macOS 10.12.3, btw]

Apple has entertained a predilection for front or 'pre' loading activity pre-need in order to 'speed' an otherwise main activity.

Spotlight, as an example, can't do it's job without an index, where the 'search' is on it, not an actual live scan of the drive, which could of course take more time than the user is willing to give. But when the index ties up resources and forces the user to wait on other tasks, any benefit vanishes. Spotlight engrs. can of course only be concerned with the load their tool imposes, because they can't know what else the user might be running...and even if there is an across the board issue, it's filed under "the next macOS will handle that better, so don't worry about it now - we're working on it". Wash, rinse, repeat.

There are no shortcuts, so the burden falls on the basics. Those are (a) fast drive, (b) max physical ram and (c) sufficient free space on the drive. Apple loves to equip their computers with SSDs, for speed, but those tend to fill up quickly, kneecapping (c) - and when that happens, unsuspecting users get the victim-blame when they don't pay attention, or simply don't know the hole they're standing in was quietly dug while they went about their work.

Xcode has always indexed projects so that they can be built and tested in a timely manner, but it's apparently gotten to the point where that process is so complex it is eating it's young*, taking center stage over usability - what can they do...mission creep = bloat. The issue is it takes as long as it takes. The response then at the dev level should be to confirm their environment, then take steps to not ask the IDE to do more than it needs to do at a given time so that wait times aren't any higher than they need to be...close projects not being worked on, etc.

*As for Xcode 8, and on the theory this is a bug, see: http://stackoverflow.com/questions/39547197/xcode-8-0-swift-3-0-slow-indexing-and-building