Date: Thu, 14 Nov 2002 15:42:28 -0800 (PST) From: Nate Lawson <nate@root.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: hackers@freebsd.org Subject: Re: cvs commit: src/bin/sleep sleep.c Message-ID: <Pine.BSF.4.21.0211141538440.44091-100000@root.org> In-Reply-To: <200211142257.gAEMvdxX071776@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Please see earlier threads on hackers@ about bloat in libc and dynamic
linking of /[s]bin. Tim Kientzle submitted a patch that breaks exit's
dependency on malloc which saves space in the programs that don't
otherwise use malloc.
I don't think a mini-libc is a good idea because bugfixes would need to be
duplicated or confusion about which one is being used for a program would
make debugging harder. I'd rather have the normal libc on /lib (modulo
some paring down of libc) and things dynamically linked.
-Nate
On Thu, 14 Nov 2002, Matthew Dillon wrote:
> I think the real issue is the bloat in libc. printf() eats 20K, basic
> stdio eats 5K. You get 15K of bloat just with a blank main(), a good
> chunk of that being malloc() (reasonable in larger programs, ridiculous
> in tiny programs where you don't care about malloc() efficiency).
>
> (static link output)
> -rwxr-xr-x 1 dillon dillon 52873 Nov 14 14:36 x printf("X\n");
> -rwxr-xr-x 1 dillon dillon 21493 Nov 14 14:36 x puts("X");
> -rwxr-xr-x 1 dillon dillon 21493 Nov 14 14:36 x puts("X");
> -rwxr-xr-x 1 dillon dillon 15109 Nov 14 14:38 x main()
>
> -rwxr-xr-x 1 dillon dillon 959 Nov 14 14:55 x _start() / no libc
> -rwxr-xr-x 1 dillon dillon 959 Nov 14 14:55 x _start() + phk malloc
> -rwxr-xr-x 1 dillon dillon 13409 Nov 14 14:56 x
>
> My zalloc implementation, which I could turn into a poor-man's malloc
> in 10 seconds (and is used in libstand) eats 1.7K. My *printf()
> core (pfmt) from DICE, which handles 95% of the capabilities of *printf,
> is 1.9K. I could adapt the stdio library from DICE to fit in probably
> less then 2K, assuming one actually referenced every single function.
>
> Why not create a mini-libc? No language-aware character conversions,
> no efficient string or memory functions, no floating point. Just a basic
> implementation of the core functionality required for stdio, malloc,
> *printf(), string functions, and system calls (which will simply be
> borrowed from libc), sufficient for simple binaries. It could be made
> compatible with our standard includes (structural bloat != code bloat,
> so who cares).
>
> I could whip this up in a day or two. I'm not kidding. I already have
> most of the necessary pieces from my embedded libraries and DICE
> libraries.
>
> -Matt
> Matthew Dillon
> <dillon@backplane.com>
>
> :
> :In message: <20021113204503.GI9006@vega.vega.com>
> : Maxim Sobolev <sobomax@FreeBSD.org> writes:
> :: On Wed, Nov 13, 2002 at 03:32:13PM -0500, Mike Silbersack wrote:
> :: >
> :: > On Wed, 13 Nov 2002, Nate Lawson wrote:
> :: >
> :: > > njl 2002/11/13 12:12:26 PST
> :: > >
> :: > > Modified files:
> :: > > bin/sleep sleep.c
> :: > > Log:
> :: > > Remove getopt and strtol dependencies, reducing size of static exe.
> :: > > Preserve older desired behavior, accept [+-]*[0-9]*\.[0-9]*
> :: > > Remove a few unnecessary casts.
> :: >
> :: > Please don't commit crap like this. While having smaller binaries might
> :: > be nice, being entered into an obfuscated C contest is not one of the
> :: > goals of FreeBSD.
> ::
> :: I fully agree - HDD space is pretty cheap today, while embedded folks
> :: should use other means to reduce footprint (e.g crunchgen). Actually
> :: in the case of crunchgen this commit worsens situation, as the code
> :: is no longer shared.
> :
> :It also makes the dynamic binary larger for the folks that have / and
> :/usr on the same partition and dynamically link /sbin and /bin. Much
> :more bang for the buck that these silly micro-optimizations. So this
> :is a negative thing as far as I'm concerned. :-(
> :
> :Warner
> :
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0211141538440.44091-100000>