Hi Christophe, I've dragged myself back to 2009 from 2004 where I've been stuck with CodeWarrior and an emulated OSX 10.3 environment with no chance of using any modern boost libs. So I hope to have a review in by the end of the week. Christophe Henry wrote:
Hi Simon,
I think it would be worthwhile talking a little more about compile time performance in the documentation.
You're right, I could explain more in the documentation. Unfortunately, the answer is not straightforward. The compilation time (and how far the compiler plays with us) depends on a number of factors: 1) the compiler 2) the compiler version 3) even your hardware (I get very different compile times on 2 different machines with the same processor) 4) the state machine structure and the chosen front-end
1) usually, g++ crashes later than VC and needed fewer workarounds 2) Surprisingly, g++4.2 > g++ 4.4. VC10 > VC9 > VC8 3) you will need RAM, especially with VC8
Indeed MSM 1.x showed g++4.2 much faster and uses less ram than VC8. Is MSM 2.x any faster or more ram frugal?
4) the compile-time is proportional to the number of transitions in the transition table and to the depth of the state machine (meaning submachine of submachine of...). EUML will cost you much more with VC than g++ as it implies a metaprogramming layer above the standard metaprogramming of the standard front-end and because the underlying decltype/typeof seems much better implemented with g++ (if you don't count the generated code size).
A small test with VC9 in Release mode (and no other code) gave me: 20 transitions => 11s 30 transitions => 16s 40 transitions => 22s 50 transitions => 31s
For 41 transitions and 5 states, I was seeing about 30s on XCode with g++4.2.x. Unfortunately the same code takes over 2.5 minutes on VC8. In fact so many compute resources were used that Incredibuild, our distributed build tool, was blocked from distributing any other compilation units for about 2 minutes. This forced me to revert to the TMP book's STT implementation which compiled in less than 30 seconds on both platforms, and allows Incredibuild to do it's job. Aah! I should mention these times are for debug builds, which is a much more important measurement in an iterative/agile development environment. It's not that big of a deal if the nightly release build takes a few minutes longer. By the way I'm on XP with 4GB ram using the /3GB switch. Interestingly if I just put all the MSM implementation inline there is about a 1 minute overall build time improvement.
This is just to give you an idea as it can greatly depend on the factors named above.
Also I'd like to see some suggestions of how to improve compile times (and how factors including the number of entries in a transition table affect the compile time).
There is just one solution: reduce the number of transitions. The best way to do it is using orthogonal regions. For example, if you see in your diagram many transitions to a single state based on the same event, you should factor them all into a second region. Adding submachines could help in some cases. On one hand, the compiler now has to generate code for a second machine, OTOH it reduces the number of transitions in the main one. This will only help if your submachine handles a small number of events, as Msm will add a row in the main table for every event of the submachines. If you can in exchange reduce the number of transitions, it can help.
My efforts at submachine refactoring actually increased compile times significantly. Also my main motivation for using the STT is it's ability to give both a forest-and-trees presentation of a moderately complex set of operations. Any refactoring just to get better compile times that obscures this ease of understanding just negates the benefits. Of course if refactoring into regions/zones exposes some underlying relations inherent in these states, transition and operations than it's fully justified, IMHO. [snip]
One of my favourite features of boost::statechart is state local storage. It looks like this would have to be done manually in msm?
Yes, this is not supported yet. However, Msm has always been developed very user-oriented and what users ask, they usually get it. Msm has
I can attest to Christophe responsiveness and willingness to accommodate users needs. Jeff