[Bug libstdc++/14563] new/delete much slower than malloc/free

["ron_hylton at hotmail dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From ron_hylton at hotmail dot com  2004-07-28 02:50 -------
I've been experiencing a severe performance problem on Cygwin with gcc 3.4.2 in 
which programs compiled with enable-sjlj-exceptions are 6 times slower than 
disable-sjlj-exceptions.  After reading the thread here I experimented with the 
new/malloc test case posted previously but modified so that the whole thing is 
wrapped in a try block.  Here are the results, all run on the same machine (2Ghz 
P4) with array_size = 100, loop_count = 3000000.

Intel Windows C++
done looping time 1=1.14
done looping time 2=1.125

VMWare SUSE Linux 9.1 gcc 3.4.2 (default sjlj-exceptions, presumably disable-)
done looping time 1=0.75
done looping time 2=0.62

Cygwin gcc 3.4.2 disable-sjlj-exceptions
done looping time 1=5.516
done looping time 2=5.265

Cygwin gcc 3.4.2 enable-sjlj-exceptions
done looping time 1=16.953
done looping time 2=5.328

Cygwin distribution gcc 3.3.1 (enable-sjlj-exceptions)
done looping time 1=17.016
done looping time 2=5.328
 
There seem to be 2 problems with Cygwin.  First, both new & malloc are 5 or 6 
times slower than on Linux or using Intel.  Second, enable-sjlj-exceptions slows 
down new by another factor of 3 on top of this.

The full configuration for the Cygwin enable case is 

Configured with: ../gcc/configure --prefix=/gcc-3.4 --with-gcc --with-gnu-ld --
with-gnu-as --enable-languages=c,c++,f77 --enable-libgcj --enable-threads=posix 
--with-system-zlib --enable-nls --without-included-gettext --enable-interpreter 
--enable-sjlj-exceptions --disable-version-specific-runtime-libs --enable-shared 
--disable-win32-registry --enable-java-gc=boehm --disable-hash-synchronization -
-verbose --target=i686-pc-cygwin --host=i686-pc-cygwin --build=i686-pc-cygwin
Thread model: posix
gcc version 3.4.2 20040720 (prerelease)

My own applications are very array-intensive so it's not immediately obvious 
that new is the culprit in my case, but there's probably a connection on the 
sjlj problem.

Ron Hylton


-- 


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