Precompiled headers won't help you; don't give you any benefit unless the headers in question are unchanging, which does not appear to be the case. The correct solution is to minimize the dependancies of that header, which is probably quite manageable and will improve your code organization.

Quote:
Can't it just check if anything significant has changed since the last build and only then recompile what is needed? ... Isn't there an compiler option to improve this behaviour?

This is exceedingly non-trivial if not impossible, and if the IDE did this, its dependancy checking phase would be much, much slower, which would increase the overall build time for smaller changes that are not requiring full rebuilds, which would be worse in the long run.

Furthermore, you don't want such an option, because it would mean you'd very often end up linking against old object files and getting some very odd behavior.

Quote:Actually, I'm not using precompiled headers, I noticed it is disabled in MSVC2005 by default. I read on an MSDN blog thats because it is actually slower than without, unless you 'use it correctly'. I don't know how to 'use it correctly'. I don't know anything about precompiled headers except that it worked nicely in VC6. Could someone point me to an article? Where do I include "stdafx.h", and what else do I need to change to take advantage of this?

This blog, I expect. The problem is not PCH - it's the /YX compiler switch "to tell the compiler to automatically select and create a PCH file"; "If you do want to use a PCH, the Yc and Yu switch still exist and, when used correctly, they will dramatically improve build times".

Generally you should create stdafx.h, stdafx.cpp (containing '#include "stdafx.h"'), and add '#include "stdafx.h"' to the top of every source file. Then modify the project properties so it has "Use Precompiled Header (/Yu)" through "stdafx.h", and then modify the properties for the file stdafx.cpp (to override those project-default settings) to say "Create Precompiled Header (/Yc)". That should be all that's necessary to make it work properly, and you just need to work out what to put in stdafx.h - usually it's useful only for large external libraries, rather than for headers from your own project (because then it'd have to do a complete rebuild when you modify one of those headers), but it's good to experiment with different things and measure the build time to see what makes it faster.

Quote:Original post by zedzeek
PCH are a huge benifit even if u invalidate the header ( i just tested )

Only in specific cases, which is why you need to be careful about what you put in the PCH file (and about how you measure the typical build time). If a particular header is included in one source file, and you modify it, then only that one source file will have to be recompiled; but if you put that into the PCH, and had it indirectly included in every single source file, then every single source file would have to be recompiled - it's the same as doing a complete rebuild after every change you make to any header file, which is horribly slow (even though PCH makes it less slow, which I think is what your numbers are showing). If you never modify the particular header file, or if modifying it is going to force a complete rebuild anyway (because it's included everywhere, and it's not an unnecessary dependency that you can untangle), then it's fine to put it in the PCH because it's not going to make the situation any worse - but in all other cases, you want the compiler to recompile as little as possible even if each file takes a little longer.