Re: [boost] [msm] scalability

Subject: Re: [boost] [msm] scalability
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2010-02-22 15:10:21

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