Re: [boost] Re: Re: [prereview request][fsm]

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-26 14:52:14

From: "Johan Nilsson" <johan.nilsson_at_[hidden]>
> "Rob Stewart" <stewart_at_[hidden]> wrote in message
> > From: Andreas Huber <ah2003_at_[hidden]>
> > >
> > > much better speed-wise. If you customize state memory management,
> construction
> > > and destruction doesn't take an awful amount of cycles. Searching that
> state
> > > container might well take longer for large FSMs.
> >
> > That's certainly an important consideration, but I was thinking
> > in terms of something built into the fsm framework, thus
> > providing the benefit for all clients versus requiring clients to
> > do work if they want the speed improvement.  If your concern
> > proves correct, then using the container approach isn't helpful.
> > However, the states' base class, which I presume is part of your
> > library, could provide a pool allocator for state objects.  That
> > would put the onus on the library, rather than the clients, and
> > would still reduce the (perceived, not proven) overhead caused by
> > creating and destroying state objects on each transition.
> 
> If you refer to my posts, I'd just like to make clear that I was never
> concerned about overhead originating from the creation/destruction (to be
> perfectly clear; memory allocation/freeing) of the state objects themselves.
> I was more concerned about the execution of the code needed to initalize the
> state objects, which is the same regardless of whatever allocators being
> used.

OK, I guess I launched off on a tangent.

You make a good argument though that *if* state objects were only
ever created once, then the initialization would only be needed
once.  The question arises, then, whether there are compelling
cases where that's the case.  For example, it would be possible
to create a state class that referred to an external object for
the reusable data, so Andreas' current design would only preclude
you from putting that data in the state object itself.  Thus, his
current design can be made to fit your desires pretty easily, so
it may argue against keeping the state objects alive.

Andreas made the remark that tying construction to entry and
destruction to exit helps with scalability.  I imagine that means
the he's worried about a potentially large number of states in
some fsm's and that keeping all the state objects alive
simultaneously could be a bad idea.  If that's accurate, my
question is whether this concern is valid.  How many state
machines have so many states that are so large that they would
cause appreciable memory problems were the state objects not
destroyed upon exit?  I have no idea, and I won't speculate.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;