Re: 3.2 builds grind to a halt
Re: 3.2 builds grind to a halt
- Subject: Re: 3.2 builds grind to a halt
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 29 Sep 2009 16:53:28 -0700
On Sep 29, 2009, at 2:21 PM, Steve Mills wrote:
On Sep 29, 2009, at 16:10:19, Sean McBride wrote:
defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 2
Yeah, that prevents the endless grinding. 2 is a bit wimpy. 8 was
fine. 12 overwhelms it. I'll try 10 later. But I *hate* having to
hack my system this way - it should just work out of the box.
It is impossible for Xcode to predict how much memory gcc is going to
use when compiling any given file. For Objective-C, C, and simple
uses of C++, the memory use is relatively small and, thus, one
compiler per core works well. Since most projects fall into that
category, the default behavior "just works" for most developers.
If it were tuned for the worst case scenario that only a few projects
encounter, then a boatload more people would complain that build times
are super long and why the heck is Xcode only compiling 1 or 2 files
at a time?!?!?
When compiling complex C++ -- lots of uses of STL, big precomp'd
header, etc... -- GCC's memory use explodes. Worse, it explodes in
unpredictable ways. A seemingly innocuous change can cause the memory
use to triple, for example.
to see if this works around the problem. My solution was to buy
craploads of RAM! Solved the problem nicely. :)
8G *was* craploads just a few weeks ago before 10.6 forced 3.2 on us.
Some questions:
1) Have you tried compiling your current source with 2.5 on Leopard?
I.e. did you change something in your source that caused gcc to start
consuming a boatload more memory than it did before?
2) When compiling on Leopard, how many simultaneously compilation jobs
did you see?
I.e. did Xcode in 2.5 launch fewer compilation jobs than 3.2?
3) Has the # of simultaneous compilations default been changed/
customized?
Obviously, it is highly desirable that this "just work" out of the
box. And, generally, it does "just work" for most developers and
most codebases. In the rare case that it doesn't, understanding the
details of the problem may be helpful in getting you back to a
productive system.
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden