Performance of basic_string::append

[Loren James Rittle]

In article < 3B2081DB.E37EE311@softax.pl > you write:

> I tested the function basic_string::append (gcc 3.0) in the way, 
> that I appended an one character string to a string, without
> preallocation:

[... see below for version that compiles ...]

> It takes 1 hour 41 min. on a PIII/750 (Linux).

> I think the extremly long execution time is caused by the locking mechanism.
> Is it really neccessary to turn the locking on in a single-thread program?

Thank you for your report.  In the future, please provide a complete
test case that can be run without us having to hack around.

The issue you raise is addressed by a threading configuration patch
already on the mainline (and hopefully to be moved to the 3.0 branch
later today).  [See However...]

I changed the scale of the test (see below for why):

#include <string>
using namespace std;

int
main()
{
  string s(static_cast<string::size_type>(1) , 'x');
  string buf; // no preallocation
  for (int i = 0; i < 50000; ++i)
     buf.append(s);
}

When compiled this way (with mainline g++):

/usr/local/beta-gcc/bin/g++ -O3 -pthread m.C

pthread_mutex_lock()/unlock() is called.

S rittle@latour; time a.out
    11r     6.1u     0.0s       a.out

According to gdb, pthread_mutex_lock was called 99768 times in the
-pthread run.

When compiled this way (with mainline g++):

/usr/local/beta-gcc/bin/g++ -O3 m.C

the mutex locking routines are *not* called when your platform has its
gthr.h abstraction layer setup properly and weak symbols are available
and/or multilibs have been correctly setup (freebsd and linux both do
and many other ELF/POSIX platforms are cool on this point as well).

S rittle@latour; time a.out
     9r     6.0u     0.0s       a.out

Only a weak unbound symbol exists for pthread_mutex_lock, in this
case.  It was not called.

However, the problem with your example has nothing to do with mutex
overhead.  It is the O(C^n) nature of the run-time due to
memory-management (and related memory copying).  In particular,
according to gdb, malloc() was called 49893 times.  And, we can only
imagine how much data copying occurred.

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672