On 16 Jan 2014 at 7:22, Hartmut Kaiser wrote:
Performance is never an after-thought. Your implementation quality so far is not up to Boost standards (as others have pointed out), the performance of the library is not convincing either. I'd suggest you withdraw your submission at this point, rework the library and try for another review once that's achieved. We have more substandard code in Boost already than necessary because of this 'let's fix it later' attitude. This 'later' never happens, most of the time - sadly.
I think it isn't unreasonable for a library to enter Boost if it has good performance *scaling* to load (e.g. O(log N)), even if performance in the absolute or comparative-to-near-alternatives sense is not great. Absolute performance can always be incrementally improved later, whereas poor performance scaling to load usually means the design is wrong and you're going to need a whole new library with new API. This is why I really wanted to see performance scaling graphs. If they show O(N log N) or worse, then the design is deeply flawed and the library must not enter Boost. Until we have such a graph, we can't know as there is no substitute for empirical testing. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/