Subject: Re: [boost] [msm] state machine construction / destruction
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-10-21 02:18:48
> MSM enthusiasts,
> I have done a performance profiling with a simple parser with 3
> implementations, plain C++, SMC and Boost MSM. I was happy to learn that
> the MSM implementation was very efficient.
> I'm having some questions about MSM space allocation, please let me know
> my understanding of things are wrong (very likely).
> I work in a high performance computing environment so I will try to
> unnecessary object constructions.
> Is it possible for the data in the state machine backend live somewhere
> external to the state machine? If that's possible then I can put the
> machine's internal states close to the data that needs to be manipulated
> the state machine itself is data-less and I can have a single copy of the
> state machine and each data item carries everything. I know this breaks
> encapsulation but I'm just wondering.
No, all the states are constructed at the same time (fsm creation) and live
together in a fusion set. I'm thinking about allowing different construction
schemes but it's not going to be in the short-term.
You can of course have in the states a pointer to the data but it's probably
not what you're looking for. Sorry, at the moment it's not doable.
> The state machine has a events queue (std::deque?), can I choose to not
> this and other data structures I don't think I will need?
You can do 2 things:
- replace the queue by something more efficient (like a
boost::circular_buffer) if you need the queue but are stuck with a bad deque
- remove the queue if you don't need it (meaning no posting of events during
transition processing, no exit pseudo-states). To do this, provide a
no_message_queue typedef. See:
If you didn't use this yet, you might still not be getting the best speed
out of msm. Providing also no_exception_thrown will get you a tick more
Please let me know whether the performance inproves (with compiler / target
system if possible), I'm very interested in msm performance.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk