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

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-05-26 04:09:56

"Rob Stewart" <stewart_at_[hidden]> wrote in message
news:200405251832.i4PIW7G18701_at_lawrencewelk.systems.susq.com...
> From: Andreas Huber <ah2003_at_[hidden]>
> >
> > > Could the fsm manage a container of (pointers to) state objects
> > > that it populates as it first creates each state object and from
> > > which it retrieves a state object when transitioning?  IOW, the
> > > first time the fsm encounters the need to transition to a given
> > > state (from A to B, say), it creates B and tracks it in the
> > > container.  Upon transition back to A, the fsm locates state A in
> > > the container and reuses it.
> >
> > This is certainly possible. I just have my doubts whether this approach
is so
> > 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.

// Johan