Subject: Re: [boost] [Fibers] Performance
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-01-16 08:42:27
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.
-- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk