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? Jonathan