Christophe Henry wrote:
David Abrahams wrote:
The idea would be to do all parts that are “hard on the compiler” at runtime. I don't see why you should have to sacrifice features.
I promised to make an analysis of which feature costs how much compile-time and test your point. I hope to bring a beginning of an answer and hope you will enjoy the trip to VC++ world ;-)
I took the iPod example from the last BoostCon and compile it with VC8 and VC9 in Debug and Release. I think it is an interesting example: submachines, orthogonal regions, a good number of states. I also took the MPLLimitTest example (80 transitions, 80 states) to check a wide state machine not factored into any submachines. Both can be found in the sandbox in libs/msm/doc (/iPod or directly for the MPLLimitTest).
So, the results: VC9 (Release): 60s VC9(Debug): 79s VC8(Release): 64s VC8(Debug): 183s (!!!)
...
I didn't see why Debug took so much longer, so I played a bit with the compiler options until I found the culprit. If we now deactivate the /Gm option ("Enable minimal rebuild") in Debug (not activated in Release), we now see a big difference: VC9(Debug): 58s VC8(Debug): 62s
Waow! 20s better for VC9, 102 for VC8. This could explain Jeff's problems. This is what I call a successful optimization from the compiler to create a minimal rebuild. Now Debug builds are faster than Release (due to shorter link time if you ask).
Sorry for the delay. That is awesome Christoffe! I've turned off /Gm for all my projects and my state machine now compiles in the 6-sec range, and Incredibuild is able to keep the entire compile farm running at capacity. You shaved >30% off my full build times. Jeff