RE: [boost] Re: std::complex design (Was: N-Dimensional array lib rary submission...)

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-06 16:31:31

From: rwgk [mailto:rwgk_at_[hidden]]
> 
> --- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> > > Unfortunately the reserve() solution eventually requires
> > > use of push_back(), which is also slow.
> > 
> > If you use push_back() following reserve(), there is no performance 
> penalty.
> > The push_back()'ed object is copied into the next element.  If you 
> exceed
> > the size allocated with reserve(), then push_back() will cause 
> reallocation
> > and copying, so be sure to choose the right size when calling 
> reserve().
> 
> Here is an example push_back() implementation:
> 
>       void push_back(const ElementType& x) {
>         if (size() < capacity()) {
>           new (end()) ElementType(x);
>           m_incr_size(1);
>         }
>         else {
>           m_insert_overflow(end(), size_type(1), x, true);
>         }
>       }
> 
> I doubt that the optimizer can entirely remove the
> overhead associated with incrementing the size,
> and it can certainly not remove the "if" statement.

The memory for the vector is not reallocated, and the elements are not
copied from the old to a new allocation.  That is, with a judicious call to
reserve() before push_back(), size() < capacity() will always be true, so x
will be copied into the uninitialized memory at end() and the size will be
incremented.  Thus, there is no memory/copy performance penalty which is
what I thought "slow" was meant to imply.  If a comparison of two integers
and the increment of another is more overhead than you can bear -- though it
certainly doesn't justify the label "slow"! -- then you need a fixed-size
array such as a C array or a wrapper class of a C array.

Rob
Susquehanna International Group, LLP
http://www.sig.com