[boost] Re: ANN: review of FSM library starts

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-02-24 12:55:07

Simon Gittins <Simon.Gittins <at> maxgaming.com.au> writes:

[snip code]
> Easier, but less consistent.
> 
> In complicated fsms (many transitions, lots of state local data and
> functions), I find it extremely useful to separate the 'state' (as it
> would appear on a state chart) from the 'other stuff' (local variables,
> local functions - anything looking like 'normal' c++).  Given that
> guards tend to be fairly common in real world fsms, we should be able to
> spot them in the same way we spot normal transitions.  

Ok, I have added this to the to-do list. 

> > > The library produces large binaries.
> > 
> > The produced binaries certainly will never be small. Out of curiosity,
> > do you have any numbers (number of states -> size of executable)?
> > 
> 
> I just ran a few tests.  The original camera example compiles to 103k
> using -O3 and -DNDEBUG (and the other options specified in the Makefile
> in the distribution).  When stripped, the size came down to 56k.
> 
> I added a new nonsense state in Shooting.hpp:
> 
> struct Shooting2 : fsm::simple_state<Shooting2,Camera,
>   fsm::transition<EvShutterRelease,NotShooting> >
> {};
> 
> I also changed Shooting's EvShutterRelease to transition to the new
> Shooting2 state.  The compile size increased to 111k, and the stripped
> size increased to 61k.

I did the same with MSVC and got no difference (both exes are 48KB). I guess 
this is due to padding to the next 4KB.

One reason for the existence of the BitMachine example is to demonstrate 
executable sizes. With the current version I get the following sizes (all with 
the lib out of the box):

# states, #transitions, executable size (KB)
 2,   2,  32
 4,   8,  29
 8,  24,  52
16,  64,  72
32, 160, 128

So, it seems that 30 states and 158 transitions fit into 96KB

> In my application (as described below), I added a state with 9
> transitions that was empty otherwise.  When compiled with -g and
> stripped (our current 'release mode'), the size of the executable
> increases by around 30k.

Hmm, that's definitely more than I would have expected. Judging by the numbers 
above it seems that transitions do not have a huge effect, at least not with 
MSVC. However, the BitMachine FSM is totally flat. I assume your machine is 
hierarchical, which makes certain transitions more complex and the associated 
code bigger.
I also expect the code size to vary hugely with the agressiveness of the 
compiler at inlining and global optimizations. I hope I'll find the time to 
make some tests with switching these on and off.

> I didn't spend too much time on these tests, and I ran them with a
> version of boost::fsm that is a few months old (my apologies).

No worries, I don't think there will be much difference to the current 
version. Thanks for the tests, BTW.

Best Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.