Lots of times Xcode (seemingly randomly) starts to run extremely slowly- it can take around fifteen seconds to move an object in IB, or compiling after changing one line of code can still take up to ten seconds. I took a look at my Activity Monitor, and this is what I found:
My question is, is this normal?
2GB of RAM is way more than enough, even for latest versions of Xcode.
Looks like you've hit one of the bugs in Xcode compilation / indexing / syntax hilighting. c.f.: Xcode 4.3.2 and 100% CPU constantly in the idle time
You only have 2GB's of RAM. With each update to Apple's software, they get more memory intensive. The same goes with Safari 5.1+. So to answer your question, Yes, this is normal for a machine with 2GB's of RAM running Lion as well as other memory intensive applications, Chrome being another.
As for Interface Builder, I have noticed this too. XIB's are XML files, so I believe as you move an object, Interface Builder is writing it's location on the view as it is moved, so that is a very data heavy task as well.
XCode is usually around 20-30% CPU sitting in the background doing nothing. It's a pig that's all.
Related
I’m trying to build my Swift app and, as the title states, it never finishes building and eventually I get a warning for critically low system memory. I have about 23GB free on my computer but as soon as I hit build and watch the memory usage on Activity Monitor the Swift process gradually increases in size, reaching tens of gigabytes in size until my computer dies. This only recently started happening but I don’t know how to solve it. It also seems to happen whilst Xcode indexes my project. It gets stuck at the "Compiling Swift sources" stage. Does anyone have a solution?
I solved it! The problem was I had a function that was a bit complex and it was returning a value, but I had set the function as void. I tracked this down by removing files that I'd recently changed from the target and then compiling to see if it would give an error or just compile forever. Then I commented out bits of code.
I solve it by cleaning the code first (shift+command+K)...
Then keep it free for indexing...
After that rebuild (command+B)...
And it works fine...
I have noticed this issue today when i started my computer. My fan is making a lot of noise as if its overworking and my CPU usage is 100%. Though i am not running any other application but Google Chrome. Now, i went to taskmanager and checked out the process that's taking much of my CPU and found this "system" thing which is almost consuming 80% of my CPU. Now, when i clicked on the file location it turns out to be located in the Windows->System32 folder. Now, i want to minimize my CPU usage. What should i do?
Press Windows key + R and type devmgmt.msc and look for errors, broken devices, unknown devices, etc. and fix/update where necessary.
ntoskrnl.exe is your kernel.
Increased CPU usage of this is often caused by driver-related issues.
Our iOS automation tests on simulator have gone through disaster since upgrading to Xcode6.
We can observe view switching slowing down, UIAutomation felt it too and often returned an empty or not fully updated app main window, you can imagine the stability.
Part of the reason is that we have slow VMs, but still we need to find ways to workaround it.
Then I notice there's the CoreSimulatorService process staying alive between the launches and shutdowns of simulator. So I killed it to see what change would it make:
killall -9 com.apple.CoreSimulator.CoreSimulatorService
After it was killed and relaunched, the performance of simulator seem to get much better, at least I don't see random fails anymore (hopefully). I guess this is kind of cleaning up.
So I hope to get a better idea about what function does CoreSimulatorService perform exactly?
Also, I am confused about where to find the documents when Apple releases new things (forgive my ignorance). For example, I didn't find any documents in iOS developer library mentioning simctl except Xcode Release Note.
Thanks!
I just faced a unexpected CPU spike due to this process (Xcode 12 & macOS 12).
A quick look on the web showed that most of the time your look for com.apple.CoreSimulator.CoreSimulatorService you will find people afraid of "something" and that are resetting everything. Ultimately this will "resolve" (as a workaround) the problem that isn't really one.
I opened ActivityMonitor (and not just looking at iStat Menu CPU widget), I found that the process update_dyld_sim_shared_cache was responsible for this CPU high usage.
Just reading the name show that the process is probably doing something expected after all (I got this issue after an OS update).
I just waited a around half a hour and the CPU went back to normal.
Since installing XCode 6 GM, it has been freezing and locking, showing the spinning wheel of death while I attempt to edit code that has syntax errors. Has anyone else seen this, and are there any known work-arounds?
I foolishly abandoned my cautious strategy of saving the previous version (Beta 7) and it appears that Beta 7 is no longer available for download. Are there any known archives of / for the link?
I have also posted to the dev forums and will follow up with a bug report, but it is hard to pin down the exact circumstances.
Edit:
Additonal Notes:
CPU: SourceKit Service is generally around 100%, but that has seem to have been the norm for the flavors of XCode, and the CPU seems to properly drop off when it finishes recompiling.
RAM: SourceKit is no longer exhibiting the memory leaks that used to cause it to halt and catch fire, memory does not appear to be a factor, and there are several ~ 5+ gigs to spare.
Environment:
Late 2012 Mac Mini, 16GB RAM
OS X 10.9.4 (to be fair, this was new today as well, driven by the requirements of XCode 6 GM).
That said, only the software changed today.
Update
Apple claims that this bug is fixed in Beta 6.1, for what it's worth.
You should look if you have any imports missing in your bridging header file. Sometimes even commented out imports will cause this behaviour. For me it was commented out Pixate Freestyle Cocoa Pod. I had to remove pod completely from my project to stop SourceKitService from crashing.
https://stackoverflow.com/a/25173389/527539
I can't say any of these fixed the issue, but they alleviated the situation:
I removed all playgrounds from the project tree. Saved them somewhere else.
I removed all objectiveC code from the swift project (when possible). This Spinning-wheel, BTW, is a problem only in my swift projects. My other Objective-C-only projects are fine.
It looks like it's the background indexing process which is taking all the CPU. Open "Activity Monitor" and see it right there at the top, using 360% CPU. Lowering the priority for this process helped as well (type in terminal):
renice 10 -p [pid]
Make sure to take the correct process id from Activity Monitor.
The higher the number (should not exceed 19) the lower the priority.
I make significant changes one at a time. It seems that the amount of errors in the file affect how many times and for how long the spinning wheel spins. It looks like some type of errors trigger it more often than others, but I'm not able to pin point which exactly.
XCode had a similar indexing issue in previous versions (see this Xcode4 issue: How to disable indexing in Xcode 4?) which gives me the hope they will fix this issue sometime, hopefully soon...
I create a new tab via menu File->New Tab and close the old tab that is frozen.
CmdT does not work that time.
At work we are using some pretty powerful machines: HP Z600 with dual xeon #2.5GHz, 8-16GB ram. Unfortunately due to ill-fitting company policies we are forced to use 32-bit XP, so I made a PAE ramdrive out of the unused 4GB RAM.
Now, the temporary files are on the ramdrive. I've also tried moving the whole project to the ramdrive, then to an SSD, but there was no noticeable improvement in hosted-mode startup or compilation times.
I've then run SysInternals' Process Monitor to see if there are any bottlenecks that are not visible with task manager / hard-disk activity led, but I have not seen anything notable - except some buffer overflows which I don't understand what they mean.
I can assume that performance for OOMPH startup and GWT compilation are tied so I'm using the compilation times as benchmarking between various changes.
I've activated and deactivated hyper-threading and turbo-boost in BIOS, but again saw no differences. Hyperthreading even seems to make everything slower, I can assume that context switching penalty is higher for 16 cores than for 8 cores. Turbo-boost does not seem to do anything, I can assume it only works under Win7, I have not succeeded in activating the driver. It should boost the core from 2.5Ghz to 2.8Ghz.
Deactivated indexing and timestamping on NTFS drives, changed the performance setting from foreground to background and back, used another instance of Eclipse - no changes.
For compilation I've tried specifying a different number of workers, larger memory and some other options. Everything above two workers increases compilation time.
Older HP machines (XW6600) seem to compile a bit faster, perhaps because of the 2.8GHz clock, but their hosted mode seems to start up slower.
To sum up, memory usage is at about 2.6GB, pagefile usage is zero, harddrive is not signaling much activity, CPU activity is <10% (single core at about 50-70%) but still the computer seems to do nothing for some time while compiling or launching OOMPH GWT.
Ok, so now that I've tried everything I knew and found on the Internet, is there anything else that I can try? Will switching to 64-bit Win7 improve much (this is due next year anyway)? Are there any hardware/software options that I can tweak?
L.E.: also ran RATT (tracer from MS) to see if there are any interrupts taking too long, but everything seems in order. Antivirus does not make a difference. Benchmarked another GWT project against my i7 mobile (2630q) and the i7 is about 70% faster, though it has about the same clock.
In most cases I've encountered the reason for slow compilation/hosted mode refresh is that application is written this way.
For compilation there are few things to watch out for:
Don't keep unused classes and modules in your classpath, remove them if possible because GWT is parsing them anyway at precompile stage
whatch out for GWT-RPC type explosion, this is usually a cause of all problems
Be really carefull with interface ContextWithLokup, always try to minimize the number of methods used in interface which extends ContextWithLookup
Try to check out some other compilation options, like distributed compilation , soft permutations or multi-jvm compilation (run compiler with system property -Dgwt.jjs.permutationWorkerFactory=com.google.gwt.dev.ExternalPermutationWorkerFactory and -localWorkers to specify number of JVMs)
For hosted mode:
Use lazy loading where it is possible. The greatest problem with hosted mode i saw, i that application is trying to initialize too many classes which aren't even used on current screen, this can greatly speedup a hosted mode startup. Again, stuff like RPC type explosion affects hosted mode as well
That's all I can advise. Stuff like ram disk can speed up stuff like -compileReport, since it can generate a huge number of files.