From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-02-24 12:55:07
Simon Gittins <Simon.Gittins <at> maxgaming.com.au> writes:
> 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
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.
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk