Re: includes/imports in gui.

[Richard Frith-Macdonald]

On 18 Feb 2010, at 09:51, Nicola Pero wrote:

>> I'm not convinced by the other part of the argument (about precompiled 
>> headers not being much faster),
> 
> I think the problem is there is a perception that precompiled headers are 
> "much faster" when used.  I had that perception
> too, until I tried them out :-)
> 
> Renaissance uses them, and I just looked at a random file 
> (GSAutoLayoutManager.m) to get some data for you.  On a test
> machine, compiling it  without precompiled headers takes 0.61 sec, and 
> compiling it with precompiled headers takes 0.45 sec.
> (after priming all caches etc, 10 results with mean deviation below 0.01 sec 
> etc).
> 
> That is faster, but to be honest not "much faster".  Using a precompiled 
> header reduces compile time by about 25% (note how this
> is the maximum speedup you'll ever get in a build from precompiled headers).
> 
> But, creating the precompiled header itself requires 0.8 sec (on same 
> machine, same conditions).
> 
> So, to do a full build, you save 0.16 sec per file you compile, but you 
> consume 0.8 to generate the precompiled header first.  If you compile less
> than 5 files, it's not worth it.  If you're doing things in parallel, you 
> have to multiply that, eg, if you compile with "-j 4" and your computer
> can compile 4 files in parallel, precompiled headers are not worth it unless 
> you compile at least 20 files (since it takes 5 compilation steps
> to compile 20 files, and with precompiled headers you'd save 0.16 * 5 = 0.8 
> sec).  So if you're using "-j 4" and compile 40 files, you'll
> be looking at a compile time of 0.61s * 10 = 6.1s without precompiled 
> headers, and 0.8s + 0.45s * 10 = 5.3s with precompiled headers.  So,
> just a 14% reduction in build time over a large project with 40 files.  (and 
> if you had, say, 24 files, you'd be looking at almost no speedup;
> if you had 16 files only, you'd be looking at a slowdown!).
> 
> All new CPUs coming on the market are 4-core CPUs.  So in a couple of years 
> everyone will do 'make -j 4' as standard.  Servers use powerful
> CPUs and often are dual-CPUs; on these machines, 'make -j 8' will easily be 
> the minimum you do - the perception that precompiled headers are
> "much faster" in that situation is an illusion.  A large project will 40 
> files will require 5 steps to compile with 'make -j 8', meaning using a 
> precompiled
> header won't be any faster than building without it!  Anything with less that 
> 32 files will simply compile slower with a precompiled header.  And at the
> next doubling of CPU cores, it's hard to find any Objective-C project that 
> will compile faster with a precompiled header. ;-)
> 
> --
> 
> Of course, if you are developing, and need to recompile your code after a 
> change, you'd already have your precompiled header.  So if you change
> two files and recompile, you have to wait 0.45s instead of 0.61s for them to 
> be compiled.  That's when precompiled headers really work great - I guess
> this is the case you were referring to when you talked about precompiled 
> headers being "cached".  And it's a very good point - in this case using a
> precompiled header will always be faster.  But the improvement is hard to 
> notice in practice.  You'd be saving only 0.16s on your build.

Thanks very much ... I always find real numbers (or provable reasoning from 
established facts) much more convincing than general statements/opinions, and 
that seems clear enough for even me to understand.

It has a small effect on how we should organize headers in base too:

I want to clearly separate out non-OSX stuff from OSX stuff, so that our 
extensions would all be available to OSX users in the base-additions library.

I was hoping to just have all the extensions headers collection in Additions.h 
and have Additions.h included in Foundation.h for backward compatibility ... so 
existing Apps which include foundation.h and expect to use our extensions would 
continue to be able to do so.

But ... if people aren't going to want to include Foundation.h (because it's 
slow), perhaps the individual headers should be made to import the extensions
(eg NSString.h would import GNUstepBase/NSString+GNUstepbase.h unless 
NO_GNUSTEP is defined).

Alternatively, perhaps we need to update all projects to explicitly include the 
headers for the extensions (irritating work to do)... I'm not sure what to do 
here.