"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Sat, 12 Mar 2005 15:57:10 -0500, David Abrahams wrote
Haven't a few people been reporting that they won't even begin to apply this one because of particular limitations? Anyone who needs higher performance won't even get started.
Sure, and on the other hand we've had at least one testimonial that this was the best fsm library they found -- served them well in a project. I've heard the same sort of argument from people comparing std::string to a char*. std::string: "it's too slow for my app". Fine for them, well at least until they leak memory in their app, (of course, they won't use shared_ptr either -- too much memory). That doesn't make std::string less useful for me or thousands of other programmers. I'm interested in using fsm in distributed server apps where the library overhead is completely irrelevant to application performance. The documentation was certainly upfront about the performance implications -- so it doesn't try to misrepresent itself -- if it did I would have major problems.
All true, but I don't see what bearing it has on the likely evolution of the library. Remember, I am not making any argument about whether to accept the library here.
Users suggest and submit enhancement ideas -- sometimes fully coded.
Nobody ever submitted me anything that could be thought of as a progressive step towards the two major redesigns I've done (Boost.Python and Boost.Iterators). The redesigns took a great deal of imagination, the sort of thinking that someone who's just trying to get his own work done can't really afford to do.
Fair enough, but there have been major submissions for other libraries -- some more radical than others. I know there have been user submissions for design changes related to signals performance that Doug has been looking at. Perhaps it's a question of what you and I define as 'major redesign'....
Anything that requires a fundamental rethink of the library's approach.
I haven't read every last word, of the reviews, but what I did read seemed like a mostly healthy interchange of possible ideas and limitations with various approaches.
I don't understand why you're saying that. I made no judgement about the health of the conversation.
Well, my take was that Andreas was quite open to discussing the options and directions that would lead to better performance. Others seem to think that Andreas has closed off all viable options,
Maybe some others; I didn't think that.
but maybe I'm the one that's misreading the conversation.
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. 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. 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. 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com