This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/14563] new/delete much slower than malloc/free
- From: "ron_hylton at hotmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 28 Jul 2004 02:50:20 -0000
- Subject: [Bug libstdc++/14563] new/delete much slower than malloc/free
- References: <20040312233606.14563.paulthomas2@wanadoo.fr>
- Reply-to: gcc-bugzilla at gcc dot gnu dot 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