From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-12 15:31:45
Andreas Huber wrote:
> Jonathan Turkanis wrote:
>> 2. If I object to part of your library I should offer a concrete
>> proposal to fix it
> Either that or prototypes of techniques of which I said I can't see
> how they will work. I said that because I have invested considerable
> time in discussing things that might come to mind when one wants to
> improve performance. I can't think of much else I can say in support
> of the current design performance-wise. So I thought it would be more
> productive if you or anyone else could make concrete proposals. Such a
> proposal would either send me back to the drawing board or I would
> need to argue convincingly why it doesn't work.
I've read the documentation and most if not all of the review discussion, and
still I do not find your explanations satisfying. It's very tempting to try to
design an FSM library with better performance characteristics, but I don't have
anywhere near enough time, esp. because I'd have to start out by becoming an FSM
expert. I don't think I should have to do this before writing a review.
>> 3. If I want to understand where the performance bottlenecks are, I
>> should examine the code.
> No, I didn't mean that in the generality your summary suggests. In
> *one* *specific* case I thought it is better if *you* (Jonathan) look
> at the code before I explain all the details in text. I did that
> because I *assumed* (maybe wrongly) that you want a very detailed
> description for which I really don't have the time at the moment.
But this one specific case -- the expense of implementing state local storage --
forms the basis for your argument that dispatch time is not so important, right?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk