rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) (03/14/88)
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.
flaps@dgp.toronto.edu (Alan J Rosenthal) (03/16/88)
rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) writes: >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?
franka@mmintl.UUCP (Frank Adams) (03/17/88)
In article <2304@uvacs.CS.VIRGINIA.EDU> rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) writes: >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
ugfailau@sunybcs.uucp (Fai Lau) (03/21/88)
In article <2770@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: > >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 BI: ugfailau@sunybcs
rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) (03/21/88)
In article <2770@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: > 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!virginia!uvacs!rwl | | Department of BITNET: rwl8y@virginia | | Computer Science, CSNET: rwl@cs.virginia.edu -OR- | | University of Virginia rwl%uvacs@uvaarpa.virginia.edu |