Re: includes/imports in gui.

[Nicola Pero]

> 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

PS: The tests above were with Renaissance, which includes Foundation/ 
Foundation.h and AppKit/AppKit.h.  If you try with gnustep-gui, which  
only needs
Foundation/Foundation.h, the results are even more disappointing as  
the benefits of using a precompiled header are even smaller!  And  
gnustep-gui currently
tends to only #import the Foundation headers that it needs ... so the  
benefits from switching to #importing the entire Foundation/ 
Foundation.h and precompiling
it are even smaller ...