2015-07-03 17:51 GMT+02:00 Jonathan Wakely <jwak...@redhat.com>: > As well as reducing the number of lists we construct when sorting this > also allows us to range-check and ensure we don't overflow the > fixed-size array (we now get an exception if that happens, although > that's probably not possible even on a 64-bit machine). > > Unfortunately this seems to hurt performance, presumably the extra > indirections to the _ListSOrtBuf rather than just an array of lists > confuse the optimisers. > > Does anyone see any better solution to this? (other than rewriting the > whole sort function, which I think has been proposed)
I have not yet thought about better solutions, but: - Isn't it necessary to cope with possibly final allocators when unconditionally forming the derived member class struct _Impl : allocator_type ? Maybe you could just define that as a non-deriving aggregate? - Daniel
