[Bug libstdc++/20706] New: string::reserve severe performance regression

[Bug libstdc++/20706] New: string::reserve severe performance regression

[ftr at highstreetnetworks dot com]

I am experiencing severe performance degradation using string::reserve() under
libstdc++.so.6 (g++ 3.4.3) that was not present under libstdc++.so.5 (g++ 3.2.2).

Here is a test program that exhibits the problem:

#include <string>
#include <assert.h>

int
main(int argc, char **argv)
{
	unsigned long size = 1024 * 1024;
	char *data = (char *) malloc(size);
	for (unsigned long i = 0; i < size; i++) {
		data[i] = 32 + (i % 94);
	}

	std::string dest;
	for (unsigned long i = 0; i < size; i++) {
		dest.reserve(dest.length() + 1);
		dest.append(&data[i],1);
	}

	assert(dest.length() == size);
	assert(dest == std::string(data,size));
}

Running linked against libstdc++.so.5 returns:
$ time ./test_reserve

real    0m0.128s
user    0m0.109s
sys     0m0.010s

Running linked against libstdc++.so.6 returns:
$ time ./test_reserve

real    13m34.776s
user    5m44.582s
sys     7m50.130s

On a 3.20GHz Xeon!!

g++ -v on RH8.0 returns:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)


g++ -v on RHEL4 returns:
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)

-- 
           Summary: string::reserve severe performance regression
           Product: gcc
           Version: 3.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ftr at highstreetnetworks dot com
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/20706] string::reserve severe performance regression

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-03-31 20:56 -------
This is not a bug, it's the intended, standard conforming, behavior.

This is happening because, when you call dest.reserve(dest.length() + 1) the
string class is actually *shrinking* the capacity of the string, which at that
point, is *larger* than dest.length + 1. This implies slow reallocations.

In 3.4 (at variance with 3.3) we honor shrink requests, which happen when
reserve is passed an argument which is smaller than the current capacity. This
is very useful to spare memory, in some applications.

In order to fix the problem, make sure to always pass to reserve an argument
bigger than the current capacity.

*** This bug has been marked as a duplicate of 20114 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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

[Bug libstdc++/20706] string::reserve severe performance regression

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-03-31 21:14 -------
I should also add, that, in general, your snippet could be simpler, without
penalizing the performance: typically reserve is only called once, at the 
outset, if we can estimate in advance the final size of the string. Otherwise,
internally, the implementation is *automatically* able to quickly grow the
capacity to satisfy efficiently a series of consecutive append: in our implement
the capacity automatically doubles every time is reached by the size of the 
growing string.

-- 


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