Bug#202835: /lib/libc-2.3.1.so: Want i686 optimized build

[Johan Walles <d92-jwa@nada.kth.se>]

On Fri, 2003-07-25 at 16:49, Jeff Bailey wrote:
> On Fri, Jul 25, 2003 at 03:39:34PM +0200, Johan Walles wrote:
> 
> > I would like to have an i686 optimized glibc package.  The reason is
> > glibc is what is taking up the most time (23%) during my boot
> > sequence:
> 
> Can you contrast this against an i686-optimised version of glibc? 

I built a libc configured using the following command line:

CC=gcc-3.2 CFLAGS="-finline -fno-inline-functions -march=i686 -O2
-fno-strict-aliasing" ./configure --enable-add-ons=../linuxthreads/
--prefix=/tabort --enable-kernel=2.4.20

All libs in /tabort/lib are from that build.

Overview:

1675       2.1674  0.0000 /usr/lib/bubblemon/bubblemon-gnome2
2048       2.6501  0.0000 /bin/bash
2546       3.2945  0.0000 /usr/X11R6/bin/XFree86
5193       6.7197  0.0000 /tabort/lib/libpthread-0.10.so
6076       7.8623  0.0000 /usr/bin/perl
10361     13.4071  0.0000 /lib/ld-2.3.1.so
12331     15.9563  0.0000 /usr/src/kernel-source-2.4.20/vmlinux
16312     21.1077  0.0000 /tabort/lib/libc-2.3.1.so

The total boot time has gone down by three and a half percent, from
roughly 8000000 samples to 773000 samples.  The largest contributors
seem to be libc and libpthread.

The libc numbers are as follows:

000759f0 330      2.04246     __cfree
000792f0 414      2.56236     index
0006ae90 436      2.69852     getc
0007c0b0 441      2.72947     memset
00057e40 522      3.2308      _IO_vfscanf_internal
00075830 552      3.41648     __malloc
0007c6f0 640      3.96113     memcpy
00076670 1244     7.69945     _int_malloc
00079460 1603     9.9214      strcmp
0007c020 3521     21.7924     memmove

Inside of libc, strcmp(), memcpy(), __malloc() and
_IO_vfscanf_internal() have all improved notably.  memmove() on the
other hand actually seem to do worse now (both as an absolute time and
as a percentage).

  Cheers //Johan