What are the pros + cons of Link-Time code generation? (VS 2005)
I've heard that enabling Generate Code Generation (/ LTCG switch) can be a major optimization for large projects with a lot of communication libraries. My team uses it in the Release configuration of our solution, but the long compilation times are a real drag and drop. One change to one file, that no other file depends on triggers for another 45 seconds "Code Generation ...". Release is of course much faster than Debug, but we could have achieved the same speedup by disabling LTCG and just leaving / O 2.
Should I leave it / LTCG enabled?
source to share
It's hard to say because it depends mostly on your project - and of course the LTCG quality provided by VS2005 (which I don't have enough to judge). At the end you will need to measure.
However, I wonder why you have so many problems with additional release build times. You should only distribute reproducible, stable versions with versions that have reproducible or archived sources. I've rarely seen a reason for frequent, incremental releases.
Recommended setting for the team: Developers usually only create incremental debug builds on their machines. The release build should be a complete build from source control to redistributable (binaries or even installations), with a new version number and source tagging / archiving. Only they should be provided to internal testers / clients.
Ideally, you should move the complete assembly to a separate machine, or perhaps a virtual machine on a good PC. This gives you a stable environment for your builds (including third party libraries, environment variables, etc.).
Ideally, these builds should be automated ("one click from control source to install") and should be performed daily.
source to share
It allows the linker to do the actual compilation of the code, and so it can do big optimizations like inlining.
If you are not using LTCG, the compiler is the only component of the build process that can inline a function, as in the case of replacing the "call" with a function with the contents of the function, which is generally much faster, the Compiler will do this anyway for functions where it gives an improvement.
Therefore, it can only do this with functions that the body has. This means that if a function in the cpp file calls another function that is not implemented in the same cpp file (or in a header file that is included), then it does not have an actual function body and therefore cannot insert it.
But if you are using LTCG, this is the linker that does inlining and it has all the functionality in all the cpp files of the whole project, minus the links to the lib files that were not built with LTCG. This gives the linker (which becomes the compiler) a lot more to work with.
But it also makes your build take longer, especially when making additional changes. You might want to include LTCG in your release build config.
Please note that LTCG is not the same as profile-based optimization.
source to share
I know the guys at Bungie used it for Halo3, the only thing they talked about is that it messed up its deterministic replay data sometimes.
Have you profiled your code and determined you need it? We actually run our servers almost entirely in debug mode, but in a special case, a few files profiled as performance critical. This worked great and all problems were debugged when problems occurred.
Not sure what application you are building, but break up the data structures to match how they are handled in the code (for better cache coherency). It was much more beneficial for us.
source to share
I found that footers take longer to compile and that .obj files created in this mode (LTCG enabled) can be very massive. For example .obj files, which can be 200-500k, are around 2-3MB. It just happened to me that building projects in my chain resulted in a 2GB folder, the bulk of which were .obj files.