Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!dartvax!eleazar.dartmouth.edu!earleh From: earleh@eleazar.dartmouth.edu (Earle R. Horton) Newsgroups: comp.sys.mac.programmer Subject: Line-oriented File IO Message-ID: <13054@dartvax.Dartmouth.EDU> Date: 14 Apr 89 07:24:51 GMT References: <451@biar.UUCP> <28839@apple.Apple.COM> <4012@ece-csc.UUCP> <6987@hoptoad.uucp> <4015@ece-csc.UUCP> Sender: news@dartvax.Dartmouth.EDU Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton) Organization: Thayer School of Engineering Lines: 72 In article <4015@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: >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)... >> PBClear(pb); /* zeroes a ParamBlockRec 1st time */ pb->ioParam.ioRefNum = _iofrefnum; /* obtained from FSOpen earlier */ pb->ioParam.ioBuffer = tmpline; /* buffer to hold input line */ pb->ioParam.ioReqCount = NSTRING; /* size of tmpline */ pb->ioParam.ioPosMode = 0x0080 | (EOLCHAR << 8); PBRead(pb,FALSE); /* Repeat until you get 'em all. */ >>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. > 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... > ...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. > I have to agree with Tim on this one. Microemacs, which I ported to the Mac, uses newline mode to read in text files. In fact, the code you see above comes from my (highly modified) copy of fileio.c. I timed it against QUED, another RAM-based editor. I do not have source to QUED, but MacsBug tells me it reads in files the way Tim recommends: it gobbles up the whole file at once. I used a Mac II with internal HD SC 80 and with the RAM cache turned off. I made several tests with each editor, reading into a buffer the file {MPW}AStructMacs:FlowCtlMacs.a from MPW 2.0.2. This is a moderately large assembler header file with 2756 lines and 137259 characters. Microemacs read in the file in an average of 5 seconds. QUED did the job in 1.5. You really shouldn't say that something is "just not true" unless you have tested it yourself. The MacOS supported line oriented IO is definitely slower. Of course, with a small to medium source file (~10-50k) the difference is so small as to be not worth mentioning, even when reading from floppies. I have been distributing microemacs for the Mac for two years. It has used newline mode of reading text files the entire time, and I have yet to receive a complaint about speed. I do, however, expect to get lots of them now that I have publicly admitted that QUED is more than 3 times as fast at disk IO! >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. I have to agree that it's "buried in the low-level routines," but I disagree with your comment on documentation: "...Bit 7 of ioPosMode is the newline flag... The high-order byte of ioPosMode contains the newline character." Looks pretty durn straightforward to me! Note that on the Mac, the newline character can be anything from '\0' to '\377' inclusive. Bet you can't get fgets() to do that for you! Earle R. Horton Graduate Student. Programmer. God to my cats.