Re: Performance of copy algorithm

[Nathan Myers <ncm-nospam at cantrip dot org>]

[cross-posted to libstdc++ and gcc; followups to gcc only, please.]

On Tue, Feb 04, 2003 at 01:06:43AM -0500, Jerry Quinn wrote:
> ... I started to explore the performance of the [std::]copy 
> algorithm.  The standard doesn't permit memcpy to be used outright,
> since the ranges can overlap.  The current implementation uses
> memmove whenever possible as an optimization technique.
> [followed by evidence of miserable performance in libstdc++.]

To enlarge on Jerry's comments... 

The definition of std::copy<T const*,T*> requires that, if the ranges 
overlap, the destination has to be at a lower address than the source, 
so (then) the direction of progress is prescribed.  (There's a 
corresponding copy_backward for when the overlap goes the other way.
Of course without overlap the order of copying doesn't matter.)
T and its alignment are always known at compile time, which should 
allow shaving off some crucial overhead (relative to memcpy) for 
non-char T.

std::copy<> native specializations have semantics different enough 
from C's memcpy or memmove to seem worthy of their own open-coded 
implementation, rather than being shoehorned into C's notion of 
low-level block operations.

Nathan Myers
ncm-nospam@cantrip.org