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: Joar Wingfors <email@hidden>
- Date: Tue, 29 Sep 2009 22:22:18 -0700
On 29 sep 2009, at 14.21, Steve Mills 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.
Xcode 3.2 *tries* to dynamically limit the number of jobs run in
parallel to avoid ending up in this type of situation, but as you can
probably imagine, this is not easy to accomplish, while at the same
time trying to achieve performance by utilizing the available
resources to the extent possible.
If you have a configuration where you have a decent amount of RAM
(which you do), and where Xcode is consistently still using "too much"
while building, I'd appreciate if you could file a bug report.
On 29 sep 2009, at 20.12, Steve Mills wrote:
Xcode 2.5 on 10.5 handled 16 threads with ease and never caused this
same project to grind to a halt. It was slicker 'n snot.
For comparison: I also have an 8 core, "hyperthreading", MacPro, in my
case with only [*] 6 GB of RAM, and I can run 16 compile jobs just
fine. The reason for the difference in over all performance between
our machines is probably that I'm primarily compiling ObjC code, and
that it requires much less RAM per instance of GCC.
j o a r
[*] I say "only", because even if nothing else is running at the
system at the same time that's less than 400MB *per core* - Not a
whole lot!
_______________________________________________
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