On Dec 21, 2005, at 10:54 AM, Scott Tooker wrote:
On Dec 21, 2005, at 8:06 AM, Jerry wrote:
On 21 Dec 2005, at 15:47, Sean McBride wrote: On 2005-12-21 13:51, Jerry said:
CW, then you're wasting a lot of time per day. I suspect the main trouble is that CW has the compiler built in and only needs a single instance to compile every file in your project. XCode has to call gcc in batches and so it gets the whole startup and header file parsing overhead repeated many times during a build.
So Xcode creates a new gcc process for every file being compiled? Apparently, process creation is also rather slow on Mac OS X, say some:
Not quite, it seems to batch files up in groups and invokes gcc for each group. Presumably, the group size is affected by the maximum command line length or some such limit.
Actually, gcc is invoked seperately when compiling each .o. This is a architectural issue with gcc and very well known issue.
...and before anyone brings us back around to the AnandTech article you are looking under 0.003 second process start up overhead (Linux you would see 0.0005... *rolls eyes*). In other words the actual process start up time is totally unimportant in your overall compilation time. (also the conclusion of the AnandTech article is generally bogus, the numbers are correct but not what they spin it to mean)
The "slowness" comes from gcc having to reboot strap itself for each file and the compilation process.
Generally if you can leverage zero link, predictive compilation and/or fix & continue you can avoid having to recompile code that hasn't changed (Xcode 2.2 so far has done dependency checking rather well for me). Sometimes the "problem" lies in how the dependencies in the source play out, causing the need to recompile lots of files (inlined functions in headers for example) despite a minor change.
-Shawn |