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
