From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-13 07:50:30
David Abrahams wrote:
> All I'm trying to say is that Andreas hasn't given me the impression
> that he feels high performance is a _crucial_ area for this library to
You are right inasmuch as that performance is only 2nd on my priority
list. First comes satisfying the requirements and ease-of-use. However,
it *is* important for me to deliver something that can be described as
efficient, given the requirements.
> I come at FSMs from the "pure abstraction" point-of-view; the UML
> statecharts that this library is aimed at can have all kinds of warts
> and complications (some of which are very useful) on them that aren't
> part of the basic FSM abstraction. Part of what makes FSMs fast may
> be the simplicity of the model. It seems as though being able to
> model UML statecharts is a primary design goal for Andreas, and that
> he doesn't consider providing some useful subset of that functionality
> in order to get high performance an option. I could be
> misunderstanding; someone please correct me if so.
I did consider that and tried to explain why I failed. I'm afraid that I
haven't been very successful in convincing people that the main
obstacles aren't easy to overcome.
> It seems to me that if "orthogonal states" is the only feature in
> conflict with getting the highest dispatching performance, it ought to
> be possible to design a library whose performance only degrades if you
> use that feature.
I suppose you are inferring that from what I said in
I see that this can easily be misunderstood. Fact is that the current
interface *theoretically* allows for constant time dispatch, as long as
orthogonal states are not used. If they are used you get O(n) dispatch
where n is the number of currently active orthogonal regions. However,
there are a few practical problems for which I'll probably need help to
> But this library seems to have a design that's
> fundamentally incompatible with an approach like that. To get there,
> both the interface and the implementation would have to be redesigned
> IIUC. So that sums up why I think evolving toward support for
> lightweight FSMs is not likely.
See above, a few optimizations are theoretically possible but it is
clear that the proposed FSM library will probably never earn itself the
-- 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