Sign in to follow this  
remdul

MSVC 2005 & endless re-compiling

Recommended Posts

Hi, Why is it, that when I add a comment, or change some minor formatting (without actually changing the code flow) MSVC 2005 (Express Edition) recompiles everything that depends on that header? 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? It is kinda frustrating that when I add/change/remove a comment it has to recompile almost my entire project. Thanks. :)

Share this post


Link to post
Share on other sites
While I can sympathize with the annoyance, typically the best way to resolve this is to limit your dependencies, so that most header files only affect a few source files. Forward declaring as much as possible is one way to help achieve this, and the Pimpl Idiom can be very useful to this end as well. Sometimes a significant redesign is in order, however; some designs are just impossible to untangle, so starting over is the only option left. Perhaps call it "spaghetti design", similar to spaghetti code.

Share this post


Link to post
Share on other sites
@Agony:

Well, my project is actually pretty well structured, but there's one or two classes that depend heavily on others (a Node and a Scene class), those are the ones that trigger the rebuilds. I'm trying to solve that with opaque pointers, but that's giving problems with templates (which are referring to class members).

@zedzeek:

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?

Thanks. :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
As jpetrie has pointed out, PCHs won't help here. The IDE uses the last access time of a file to tell if it has been modified - nothing more complicated than that.

As far as I know, a pre-compiled header is invalidated if the text header it has been pre-compiled from is modified.

Share this post


Link to post
Share on other sites
Quote:
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.

Yes, that was my understanding.

Quote:
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.

I meant something along the lines of a checksum of all code (comments and other unneeded characters stripped). The compiler would then compare that with the checksum of the last build of that file -> if changed -> recompile. This would work if you only changed comments or added a space here and there. Obviously, if the code itself has changed, a rebuild is unavoidable. Other behaviour would indeed be rather undesirable.

Thanks Excors for your excelent explaination on precompiled headers, I'll see if there are any benefits nevertheless.

Thanks everyone, I'll play around with it a bit more.

[Edited by - remdul on October 3, 2006 11:13:21 AM]

Share this post


Link to post
Share on other sites
PCH are a huge benifit even if u invalidate the header ( i just tested )
vc6 (which tells compile time, i dont know the switch for vc2005)
PCH with invalid header 30.6secs
no PCH with invalid header 1:52secs

i can supply a video as evidence if desired :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this