Bug#44619: libc6 performance problems - more insights
Hi,
In September 1999 I posted the problem that some programs run much
faster with the libc6_2.1.1-13.deb than with any other later version
including libc6-2.1.3-10.deb. After this first post I also made a
program which shows the problem. However the program work with the
same speed using some newer libraries, so it is not good example any
more, but my main application is still much slower using 2.1.2 or
2.1.3. I made some more research and also reported the problem with
glibcbug program. Lately I found the same problem is also with the
LAME program, so I made a package and here are the differences:
dpkg -i lame-3.82-1_i386.deb (my package)
dpkg -i --force-conflicts libc6-2.1.1-13.deb
lame -V 0 -m j check.wav
it takes 40s to complete on a Pentium-II 450MHz
dpkg -i --force-conflicts libc6-2.1.3-10.deb
lame -V 0 -m j check.wav
takes 46 seconds, which is about 15% more. Not that much but depends
on the music. The performance difference for some applications can be
up to 100% !!!!
All the necessary files are on http://r.cmm.ki.si/debian/local
page.
Speaking with the glibc people they suggested that there is a bug in
gcc with which glibc is compiled. They could get rid of problem by
compiling glibc with gcc-2.96. So my suggestion is if you compile the
library with either some other options then currently and try out the
performance or use some older or newer gcc. The option which has some
importance in this is -fomit-frame-pointer. The behavior (reduced
performance) is due to some misalignment. Using RedHat-6.1 this problem
can be somehow avoided by compiling the application with all possible
optimization options included. On Debian this trick doesn't work, so
RH uses something else to compile glibc then Debian.
If you need more data and my correspondence with glibcbug people I
can provide it...
Milan
Reply to: