[boost] Re: FSM Review

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-12 17:43:32

"Jeff Garland" <jeff_at_[hidden]> 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