Date: Fri, 15 Nov 2002 14:29:46 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: hackers@freebsd.org Subject: Re: cvs commit: src/bin/sleep sleep.c Message-ID: <20021115032946.GP6446@gsmx07.alcatel.com.au> In-Reply-To: <200211142257.gAEMvdxX071776@apollo.backplane.com> References: <200211132012.gADKCQxr062768@repoman.freebsd.org> <Pine.BSF.4.44.0211131528010.32919-100000@niwun.pair.com> <20021113204503.GI9006@vega.vega.com> <20021113.215346.90827277.imp@bsdimp.com> <200211142257.gAEMvdxX071776@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[This doesn't belong in cvs-all and Nate has already made comments in -hackers] On 2002-Nov-14 14:57:39 -0800, Matthew Dillon <dillon@apollo.backplane.com> 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). As a (partial) counter-argument: For long-running processes that make extensive use of malloc (eg /bin/sh), malloc() 'efficiency' does matter. Likewise, in an embedded environment, the 15KB of text space you save may be more than offset by a malloc implementation that is less frugal in heap space. > 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 think Nate's got a good point regarding maintainability here. If we do want to create a mini-libc, we need to minimise the amount of code duplication. Note that, based on a quick nm and size on libc.a, we could halve the size of printf() by undefining 'FLOATING_POINT' in vfprintf.c, with virtually no additional maintainability effort. (Xenix/286 used to have both integer-only and FP-aware variants of the standard libraries. The compiler would automatically select the libraries based on FP references in the code. Though I do recall managing to confuse it on one occasion). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021115032946.GP6446>