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
> address.
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
Yes.
> 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
http://tinyurl.com/7ybeq?
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
overcome them.
> 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
predicate lightweight.
Regards,
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.