Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!ncsuvx!ece-csc!jnh
From: jnh@ece-csc.UUCP (Joseph Nathan Hall)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Printing Example Code
Keywords: mac printing is a pain in the petute
Message-ID: <4015@ece-csc.UUCP>
Date: 14 Apr 89 03:18:25 GMT
References: <451@biar.UUCP> <28839@apple.Apple.COM> <4012@ece-csc.UUCP> <6987@hoptoad.uucp>
Reply-To: jnh@ece-csc.UUCP (Joseph Nathan Hall)
Organization: North Carolina State University, Raleigh, NC
Lines: 59

In article <6987@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>In article <4012@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes:
>
>>I dunno, this isn't
>>nearly as difficult as dealing with the low-level File Manager routines.
>>For example, if you want to read a text file, using the newline flag
>>(reported to exist and occasionally mentioned in the documentation)...
>
>Why would you want to do that?  Can you say "slow"?  Surely reading a
>text file in a block-by-block way is not beyond the skills of a
>professional programmer!  Remember, the key to speed is to read in
>as much as possible into the largest buffer possible.  If you follow
>this rule, the actual code calling the File Manager is nearly trivial.

Your comments about printing (deleted from above) are well taken.  But
so far as reading in "newline" mode goes:

	1) Virtually all programming environments on all major operating
	   systems support this (C, Pascal, FORTRAN, etc., on UNIX, VMS,
	   MS-DOS, etc.) at a reasonably low level in a reasonably
	   versatile manner.

	2) Why would it have to be slow?  The most common mid- to high-level
	   UNIX I/O is streamed and it's not a problem.  I just want to
	   read mid-sized text files (xx-xxxK); I don't want to sector-
	   copy volumes...

	3) Most programming tasks handled by the Toolbox and other system
	   software aren't beyond the skills of professional programmers.
	   That's not the point.  Fast character I/O (buffered by the
	   system or language run-time routines) and line-at-a-time I/O are
	   SIMPLE and USEFUL tools.  During development, who CARES if I/O
	   performance is -25% of optimum?

	4) Anyway, I disagree with the simple assertion that the "key to speed"
	   is reading as much as possible at a time from disk.  This is just
	   not true.  You can't hope for much improvement in I/O performance
	   once your buffer size exceeds the controller's buffer size.
	   You may even suffer a speed *penalty* if you do random I/O on a
	   fragmented file with a buffer size > sector size.  Furthermore,
	   in situations where it is necessary to scan the file being read
	   character-by-character anyway (when reading a text file, or
	   parsing a source that must be kept on disk, or whatever) the
	   overhead of a system-based character I/O routine can be 
	   negligible.  In systems that provide fast character I/O, it can
	   be SLOWER to do the "raw" block reads yourself if you have to
	   write the supporting code in a HLL.

The lack of explicit Toolbox support for non-block-oriented file I/O is, at
best, a weird omission.  Sure, it's there, but >hiss< >boo< it's buried in
the low-level routines and it's not well documented.  Are we just not
SUPPOSED to read text files on the Mac the same way we read them on any
machine?  Sheesh.

-- 
v   v sssss|| joseph hall                      || 201-1D Hampton Lee Court
 v v s   s || jnh@ece-csc.ncsu.edu (Internet)  || Cary, NC  27511
  v   sss  || joseph@ece007.ncsu.edu (Try this one first)
-----------|| Standard disclaimers and all that . . . . . . . . . . . . . .