Re: [PATCH] PR libstdc++/81476 Optimise vector insertion from input iterators

[Jonathan Wakely <jwakely at redhat dot com>]

On 19/07/17 22:19 +0200, Marc Glisse wrote:
> On Wed, 19 Jul 2017, Jonathan Wakely wrote:
>
> > The PR shows a fairly pathological case where ranges of InputIterators
> > are repeatedly inserted at the start of a vector. Each insertion from
> > an InputIterator moves every element after the insertion point by a
> > single position. So if we insert 1000 elements at the start we move
> > each existing element 1000 times to reach its final position.
> >
> > This patch changes insertions that aren't at the end to use a
> > temporary vector, which starts empty so insertions are at the end, and
> > so fast. Then we do a range insert to copy everything from that vector
> > at once. That uses random access iterators, so we know how far to move
> > the existing elements and can just move them to their final position
> > in one step.
>
> Is it legal to use the allocator even though capacity-size is large 
> enough for the inserted range?

The spec says no *reallocation* happens until the size would exceed
the capacity, and my change conforms to that. The vector's existing
storage is not REallocated (instead we perform one or more temporary
allocations and deallocations that are separate to the storage of
*this).

Unless I'm forgetting something, there's no requirement that we don't
perform any such additional allocations. It might be nice if we didn't
(otherwise something like a stack allocator that can't do more than
one allocation can't be used here), but I don't want to waste too much
time on this. Inserting ranges of input iterators into the middle of a
vector is a design flaw and should be avoided anyway.