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.