This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Performance of basic_string::append

In article <> 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;

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

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.

Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]