Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!scs
From: scs@athena.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: printf("%s", s) considered slow
Message-ID: <1990May4.010538.10910@athena.mit.edu>
Date: 4 May 90 01:05:38 GMT
References: <902@tmiuv0.uucp> <264@cvbnetPrime.COM> <26387BCF.390@tct.uucp>
Sender: news@athena.mit.edu (News system)
Reply-To: scs@adam.mit.edu (Steve Summit)
Organization: this line intended to be left blank
Lines: 19

In article <26387BCF.390@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>Aargh!  Why do people use 'printf("%s", s)' when 'fputs(s, stdout)' is
>faster on every C implementation known to humankind?

I always use printf.  I even use printf("\n") when putchar('\n')
would "obviously" be better.  The reason is the consistency
factor several people have already mentioned, but it's more than
just abstract warm fuzzies.  Many times I have been extremely
glad to be able to do global substitutions of "printf(" with
"fprintf(fd, " or "printf" with "output" or something similar,
and know that I've gotten everything without having to go back
and take care of puts's or putchar's by hand.

Even in a critical section where efficiency might matter, the
underlying physical I/O overhead often swamps any extra CPU time
that a "less efficient" path through stdio might introduce.

                                            Steve Summit
                                            scs@adam.mit.edu