svn commit: r227753 - in head: contrib/gdtoa include lib/libc/gdtoa lib/libc/gen lib/libc/locale lib/libc/regex lib/libc/stdio lib/libc/stdlib lib/libc/stdtime lib/libc/string

[Ian Lepore]

On Mon, 2012-01-30 at 16:26 -0500, David Schultz wrote:
> On Mon, Jan 30, 2012, David Chisnall wrote:
> > On 18 Jan 2012, at 19:07, David Schultz wrote:
> > 
> > > This patch appears to cause a large performance regression.  For
> > > example, I measured a 78% slowdown for strtol("    42", ...).
> > 
> > That's definitely worth taking a closer look at.  I think we can cache some things in TLS and avoid some pthread_getspecific calls.  The current code is the 'make it work' version.  The 'make it fast' version is planned...
> 
> Sounds good; I look forward to it.
> 
> > > Furthermore, the resulting static binary for a trivial program
> > > goes from 7k to 303k, due to pulling in malloc, stdio, and all the
> > > pthread stubs.  
> > 
> > That's not ideal, but I'm not sure if it's avoidable.  Is statically linking libc something people regularly do?
> 
> Aside from bde, probably not many.  This is definitely a
> second-order concern.
> 
> FreeBSD has a set of statically linked binaries in /rescue for
> situations where /lib gets screwed up.  Space is an issue there
> because the root partition is historically sized quite small.
> 
> Embedded folks might also care, but I'll let them speak for
> themselves.  I did get a request several years ago from an
> embedded developer to unbreak the NO_FLOATING_POINT option in
> libc, and you could imagine perhaps a NO_LOCALE option as well.
> 

If locale support starts adding a lot of cycles or memory, then we
embedded folks might like a NO_LOCALE option.  100k here, 200k there,
and before you know it you're cursing some hardware designer who was
sure that you'd never use all of the 64MB of ram he generously gave you.

-- Ian