Xref: utzoo comp.lang.c:8219 comp.sys.m6809:721
Path: utzoo!mnetor!uunet!husc6!yale!cmcl2!brl-adm!umd5!uvaarpa!mcnc!ece-csc!ncrcae!ncr-sd!ncrlnk!ncrcce!c10sd3!c10sd1!johnson
From: johnson@c10sd1.StPaul.NCR.COM (Wayne D. T. Johnson)
Newsgroups: comp.lang.c,comp.sys.m6809
Subject: Re: Don't use Scanf()
Message-ID: <344@c10sd1.StPaul.NCR.COM>
Date: 14 Mar 88 20:57:59 GMT
References: <2401@ihwpt.ATT.COM> <320@c10sd1.StPaul.NCR.COM> <1185@ucsfcca.ucsf.edu> <2428@ihwpt.ATT.COM>
Reply-To: johnson@c10sd1.StPaul.NCR.COM (Wayne D. T. Johnson)
Organization: NCR Comten, St Paul
Lines: 19
Keywords: C, I/O, library, code size

In article <2428@ihwpt.ATT.COM> knudsen@ihwpt.ATT.COM (mike knudsen) writes:
>Good points.  But if you already are using printf() in your
>program (with a legitimate need for the formatting) in several
>places, then substituting puts() where possible will make
>your program object file bigger, not smaller, since
>now the puts() code has to be linked in too.
>Puts() and putchar() will be a little faster, but when you're
>talking to humans who cares?
>

Puts and putchar may seem to be only a little faster to humans only
until you use packages that do windowing and full page menus, or even
redirect your output to disk (ever write out 3.5 meg using a printf?).
besides, memory is cheap and getting cheaper but CPU time is still costing
quite a bit.

In several instances I have found that removing several printf's that
were in critical paths of our code has remarkable speeded things up.
        -Wayne