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.