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
