After updating OSX to High Sierra and updating Xcode to 9.2.0, project build times for bigger projects got out of hand. The build times went from ~10 minutes up to ~120 minutes.
While researching I noticed that Xcode spawns xcexec child processes which take most of the cpu usage. xcexec spend almost all of the time calling the system close call. Each xcexec process calls about 2 million close calls per minute.
Upon inspecting the xcexec binary, this seems to be a wrapper tool for launching other build actions (e.g. clang).
I have fully reinstalled Xcode with no change. The build system is set to default.
What causes this behaviour?
The installation instructions for watchman instructs you to set kern.maxfiles like this:
$ sudo sysctl -w kern.maxfiles=10485760
$ sudo sysctl -w kern.maxfilesperproc=1048576
The default setting for (both of) these values is 131072 on macOS High Sierra. Watchman's suggestion is a 80x change to a performance critical setting of your kernel. Adjusting these values can result in different performance characteristics, especially for file heavy operations like compilation.
Watchman changes the limit so that it is allowed to watch more files at the same time.
Xcode however will start indexing your project and open as many files as allowed (via kern.maxfiles). During the compilation phase, Xcode launches xcexec which will close any open file descriptors for indexing and only then launch the build step sub-process. That operation should take almost no time. But after changing kern.maxfiles it suddenly does.
I benchmarked on an MBP mid 2015, macOS 10.13.3, Xcode 9.2.0.
According to my benchmarking kern.maxfilesperproc has no influence on Xcode`s build performance.
The performance of Xcode builds is heavily impacted as soon as kern.maxfiles is above 327680.
I recommend setting kern.maxfiles to (no value bigger than) 327680 if you need to support watchman with bigger projects.
Note that setting kern.maxfiles with sysctl is not persistent across reboots. Adjust the values in /Library/LaunchDaemons/limit.maxfiles.plist.
Related
I have developed several (experimental and prototype) iOS apps using Xamarin and the new Visual Studio for Mac OS and the build-times intermittently take about 5-10 minutes on average. When starting a new project, build-times are fine. After a few changes in the source code while working on my apps (no specific changes). For no reason, build times start increasing to 5-10 minutes. I've tried all possible build-options (linking, no linking, SDK versions, new consigning certificate, etc..).
Upon investigation with the Activities-app (Mac OS, Sierra) i find that the "codesign" process is taking up 110% CPU and runs for as long as the build takes to complete.
Does anyone have any experience with this problem?
I have the same issue
First Try close Visual Studio then delete bin , obj from your project , finally start visual Build and Run
Second Try make sure you build in real device sometimes emulator cause trouble , how you make sure , if build success but deploy stuck many times
In my case, after wiping my PC and completely re-installing Windows 10, my build speeds increased by 2x.
Clean builds that used to take 2:20 minutes now only take 1:20 minutes, and incremental builds that used to take 40 seconds now only take 17 seconds.
Doing an incremental build + deploying to device used to take around 4 minutes. Now it takes only 55 seconds!
I'm not sure what was leading to this awful experience, but I'm glad it's not so terrible anymore (still slow though).
Go to your *.Android project => "Properties" => "Android Options" and set the following options:
Dex compiler: dx
Linking: None
This gives me a fast build speed
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.
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.
I am aware that there are a couple of questions that look similar to mine, e.g. here, here, here or here. Yet none of these really answer my question. Here it goes.
I am building a modified version of a Chromium browser in VS2008 (mostly written in C++). It has 500 projects in one solution with plenty of dependencies between them. There are generally two problems:
Whenever I start debugging (press F5 or green Play button) for the first time in a session the VS freezes and it takes a couple of minutes before it recovers and actually starts debugging. Note that I have disabled building before running, because whenever I want to build my project I use F7 explicitly. I do not understand why it takes so long to "just" start a compiled binary. Probably VS is checking all the deps and making sure everything up-to-date despite my request not to build a solution before running. Is the a way speed this one up?
Every time I perform a build it takes about 5-7 minutes even if I have only changed one instruction in one file. Most of the time is consumed by the linking process, since most projects generate static libs that are then linked into one huge dll. Apparently incremental linking only works in about 10% of the cases and still takes considerably long. What can I do to speed it up?
Here is some info about my software and hardware:
MacBook Pro (Mid-2010)
8 GB RAM
dual-core Intel i7 CPU with HT (which makes it look like 4-core in Task Manager)
500GB Serial ATA; 5400 rpm (Hitachi HTS725050A9A362)
Windows 7 Professional 64-bit
Visual Assist X (with disabled code coloring)
Here are some things that I have noticed:
Linking only uses one core
When running solution for the second time in one session it is much quicker (under 2-3 seconds)
while looking up information on VS linker I came across this page:
http://msdn.microsoft.com/en-us/library/whs4y2dc%28v=vs.80%29.aspx
Also take a look the two additional topics on that page:
Faster Builds and Smaller Header Files
Excluding Files When Dependency Checking
I have switched to the component build mode for Chromium project, which reduced the number of files that need to be linked. Component build mode creates a set of smaller DLLs rather than a set of static libraries that are then linked into huge chrome.dll. Also I am using incremental linking a lot, which makes linking even faster. Finally linking for the second and subsequent times gets faster since necessary files are already cached in the memory and disk access is unnecessary. Thus when working incrementally and linking often, I get to as low as 15 seconds for linking of webkit.dll which is where I mostly change the code.
As for the execution it has same behavior as linking - it runs slow only for the first time and with every subsequent run it gets faster and faster until it takes less than 3-5 seconds to start the browser and load all symbols. Windows is caching files that are accessed most often into the memory.
I am working on a project using Google's cmockery unit testing framework. For a while, I was able to build the cmockery project with no problems. e.g. "./configure", "make && make install" etc. and it took a reasonable amount of time (1-2 minutes or so.) After working on other miscellaneous tasks on the computer and going back to re-build it, it becomes horrendously slow. (e.g. after fifteen minutes it is still checking system variables.)
I did a system restore to earlier in the day and it goes back to working properly for a time. I have been very careful about monitoring any changes I make to the system, and have not been able to find any direct correlation between something I am changing and the problem. However, the problem inevitably recurs (usually as soon as I assume I must have accidentally avoided the problem and move on). The only way I am able to fix it is to do a system restore to a time when it was working. (Sometimes restarting the machine works as well, sometimes it does not.)
I imagine that the problem is between the environment and autoconf itself rather than something specific in cmockery's configuration. Any ideas?
I am using MinGW and under Windows 7 Professional
Make sure that antivirus software is not interfering. Often, antivirus programs monitor every file access; autoconf accesses many files during its operation and is likely to be slowed down drastically.