Why you should use puts(3) when you don't need printf(3) 
Author Message
 Why you should use puts(3) when you don't need printf(3)

True, if you use fprintf(3) (or printf(3) or sprintf(3) for that matter) once
in a program, you have paid the penalty in terms of code size.  And true, if
you also use fputs(3) then you have added a little more size to your binary.

But what ever happened to run time-efficiency?  The point of using fputs(3) is
that it just pushes bytes to the output!  Fprintf(3) has to scan it's first
argument and gyrate around to get to the point where it pushes bytes.  The
run-time size of fprintf(3) is just plain bigger.  To give you an idea of the
relative sizes, on my VAX 11/780 running 4.3 BSD, fputs is implemented as 60
lines of assembly code whereas _doprnt (the function that *printf calls --
another bit of overhead) is 396 lines.

OK -- I'm not saying that using *printf where *puts is appropriate is going to
break the bank.  But it's good practice to only use what you need; anything
else is just lazy programming.



Mon, 17 Aug 1992 01:56:00 GMT  
 Why you should use puts(3) when you don't need printf(3)

Quote:

>But what ever happened to run time-efficiency?  The point of using
>fputs(3) is that it just pushes bytes to the output!  Fprintf(3) has to
>scan its first argument and gyrate around to get to the point where it
>pushes bytes.

On the Amiga using the Manx Aztec C compiler (v3.20a), puts() takes a
noticeable amount of time and printf() does not.  Your efficiency theories
are wrong.  (I have no idea what puts() is doing for so long.)

ajr
--
If you had eternal life, would you be able to say all the integers?



Mon, 17 Aug 1992 22:14:00 GMT  
 Why you should use puts(3) when you don't need printf(3)

Quote:

>OK -- I'm not saying that using *printf where *puts is appropriate is going to
>break the bank.  But it's good practice to only use what you need; anything
>else is just lazy programming.

There is a time and a place for careful programming to maximize speed.  And
there is a time and a place for lazy programming.  For code which is only
going to be run a few times, or code whose execution time is dominated by
physical I/O time (or user response time), lazy programming is the way to go.
--

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108



Mon, 17 Aug 1992 15:18:00 GMT  
 Why you should use puts(3) when you don't need printf(3)
Quote:

>There is a time and a place for careful programming to maximize speed.  And
>there is a time and a place for lazy programming.  For code which is only
>going to be run a few times, or code whose execution time is dominated by
>physical I/O time (or user response time), lazy programming is the way to go.

        Agree. I still remember when I first learned BASIC, the
machine was SLOW, and the interpretor was SLOW. I was writing
a mini word processor (with BASIC!!!) for my data base program
I would put like ten statements in a line, substitute "real" characters
for CHR$(n) by using a memory editor to edit the codes (you cannot write
non-ascii characters with the key board, so you have to edit the memory,)
put a machine language subroutine in a string and put the string
in high memory, porking and peeking video memory to speed up output,
etc, etc, every trick in the book.
        With today's 12MHz/math board PCs I think I'll stop slaving
myself.

Fai Lau
SUNY at Buffalo (The Arctic Wonderland)
UUCP: ..{mit-ems|watmath|rocksanne}!sunybcs!ugfailau



Mon, 17 Aug 1992 01:50:00 GMT  
 Why you should use puts(3) when you don't need printf(3)

Quote:

> There is a time and a place for careful programming to maximize speed.  And
> there is a time and a place for lazy programming.  For code which is only
> going to be run a few times, or code whose execution time is dominated by
> physical I/O time (or user response time), lazy programming is the way to go.

Sure, sure.  I was of course referring to serious coding.  But if I have
something I'm going to throw away after a few uses, I'll just write a shell
script or an awk program.  Now that's *real* inefficient in terms of execution
speed, but given the tiny amount of development time needed, it's quite
acceptable.

--
| Ray Lubinsky,                    UUCP:      ...!uunet!{*filter*}ia!uvacs!rwl    |





Mon, 17 Aug 1992 15:07:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. printf, puts, gets etc don't work when stepping into

2. why use puts instead of printf?

3. Linux(Yes, linux, I don't know where else to put it) .H file

4. VC7: cstdio doesn't put printf in std

5. Don't know why this doesn't work, but

6. replacing printf with my printf, then calling C lib's printf

7. Why don't I have System.Management?

8. Discovered the root of my problem...Why don't RichEditControls work on .NET

9. outportb: why don't work?

10. why don't this work

11. Huh? Why don't I get 777

12. I don't understand why???

 

 
Powered by phpBB® Forum Software