Jody Hagins wrote:
On Sat, 12 Mar 2005 13:42:19 +0100 "Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> wrote: [...] Thus, it seems that Andreas is not planning to make significant performance changes, and he has doubts as to the possibility that such changes are even possible. However, he has agreed to make a solid attempt to address the issues after acceptance (with the help of any volunteers), if such acceptance is granted. Maybe we should ease up a bit on the details of performance until such time as the library is either accepted or rejected. Then, we can resume such discussions as appropriate to the situation and goals of the library.
One thing that bothers me about the performance discussion is that some parties seem to imply that there exists a single best point in the design space, and that the proposed library has not found it. Given all the different constraints and values that can differ from application context to application context and user to user, I hardly see how such a stance is justifiable. Without having followed the discussion too closely or reviewed the library in any depth, I would have to say that my impression is that Andreas has put together a reasonably solid library with decent rationale for his design decisions. And isn't that Boost is interested in? Quality libraries that put correctness first and performance second? I don't believe Andreas has at any point claimed that his library is the fastest possible implementation of FSMs in existence, so why should it be held up to that goal? If the library meets the stated design goals, and if those goals are useful to a significant number of people, then the library has real utility, no? I believe that in discussions of other libraries, it has been pointed out that Boost does not exclude the possibility of overlapping libraries when there is a reason to do so. If someone else would like to propose a fast FSM library that has different design goals, possibly including performance as a primary goal, then I don't see why such a library could not co-exist with the one that Andreas has built. I don't see why such a library *should* not co-exist. What I like about C++ is choice. I like the fact that I can work with big fat structures like std::map<> or fast simple structures like builtin arrays. I like the fact that nobody decides for me ahead of time what design decisions I must make in selecting prebuilt components. I use iostreams when I can, and cstdio when I must. In fact, I did exactly that in some recent utilities that had to work on fairly large files. Is it bad that C++ has both I/O libraries? Not at all. I can write iostream code much faster than cstdio code, and more correctly with less referral to documentation. But the simple fact is, cstdio is faster, hands down. When I need the extra speed, I have that option. When I don't, I will cruise in the luxury of iostreams. I like to use std::string, warts and all. It's easy. It's convenient. It's even better than Java's String. ;) But sometimes I have to get down to char* and dirty pointer arithmetic, and that's ok. Maybe Andreas has produced the iostreams of the FSM world. I consider that A Good Thing. Maybe someone else knowledgeable about and concerned with performance will write the cstdio version. That would also be A Good Thing. But the idea that for this domain, there is a unique best solution has not thus far been defended, and I strongly suspect that such a position is, in fact, indefensible. This library already has users before becoming a Boost library. That implies that people already find it useful. It will be a sad day when Boost rejects a good library because another library in a different part of the design space is theoretically faster. Dave