I've noticed that calling std::string::reserve() in a shrink-
to-fit request can sometimes end up allocating exactly the 
same amount of memory as the string already had. 

This is because _S_create() rounds up allocations of over 128
bytes to 128 byte subpages, and of over 4k to 4k pages, for
more efficient use of malloc(). 

When the reallocated block is the same size as the original
one, the entire contents of the string are effectively being
copied unnecessarily. Further shrink-to-fit calls keep doing
it, too, since the requested capacity remains less than the
actual capacity.

NOTES:

1. I first noticed this in February 2004, and submitted a 
possible patch for it at the time - the original mailing 
list thread started here: 

  http://gcc.gnu.org/ml/libstdc++/2004-02/msg00179.html 

Unfortunately, problems at my end caused the patch to get 
hung up on FSF assignment issues, so it couldn't go in. 
I've now resolved these issues, and Benjamin Kosnik has 
asked me to put the original report here in Bugzilla for 
further discussion. 

2. Recent CVS (as of November 2004) no longer uses the 128 
byte subpages, courtesy of Paolo Carlini's work to improve 
std::string.

-- 
           Summary: Shrink-to-fit std::string::reserve() calls can
                    reallocate & copy string contents unnecessarily
           Product: gcc
           Version: 3.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: nferguso at eso dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18654

Reply via email to