Re: patch to suggest putc/fputs over printf("string") or printf("\n")

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Jamie Lokier <egcs@tantalophile.demon.co.uk>
 > 
 > On Sat, Jan 16, 1999 at 04:03:57AM -0700, Jeffrey A Law wrote:
 > >   > - putc is almost always larger than printf, though much faster.
 > > Huh?  Consider how much conversion code you bring in to handle floating point
 > > via printf...  It's utterly amazing.
 > >
 > >   > - puts requires separate library code, when just printf would have done.
 > >   >   Often, the calling sequence is the same for both.
 > > printf's library support code is quite large due to the conversions...
 > 
 > Granted.  What I really mean is: if a program already uses printf....
 > Inline putc is usually much larger at the caller than calling printf.
 > OTOH, putc when called as a function is nice and small at the caller.
 > It would be nice to avoid pulling in the floating point conversions when
 > possible :-)
 > -- Jamie

	The seperate library code you pull in from libc is usually moot
since printf may pull in fputs itself, and even if it doesn't, most
systems use shared libraries.  There are however a couple of cases where
your code gets bigger even if libc is shared.  They are when you split
one printf into multiple calls, or when you transform printf into a call
to putc which is a macro expanded to several statements.  I think we can
do appropriate checks on -Os to decide whether to do these size-vs-speed
optimizations, or to call fputc (a function) instead of putc (a macro.)

		--Kaveh

--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.