Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!jgreco
From: jgreco@csd4.milw.wisc.edu (Joe Greco)
Newsgroups: comp.sys.cbm
Subject: Re: SEQ file access speedup
Message-ID: <1017@csd4.milw.wisc.edu>
Date: 15 Feb 89 15:22:12 GMT
References: <89Feb10.182100est.2732@godzilla.eecg.toronto.edu> <7124@killer.DALLAS.TX.US> <7143@killer.DALLAS.TX.US>
Sender: news@csd4.milw.wisc.edu
Reply-To: jgreco@csd4.milw.wisc.edu (Joe Greco)
Organization: Totally Unorganized.  A Real Mess.  Award-winning.
Lines: 41

In comp.sys.cbm article <7143@killer.DALLAS.TX.US>, elg@killer.Dallas.TX.US (Eric Green) wrote:
]My basic thought was that sequential file access can take place just
]as fast as LOAD'ing. The benchmark confirms that for IEEE drives and

Why shouldn't it?  Same routines.  LOAD simply calls ACPTR in a loop.

]the standard 1541. There's a couple of constraints here. First of all,
]doing TALK and UNTALK (chkin/clrchn) for each sequentially-read byte
]is extremely slow. When you do chkin or clrchn, each call sends a
]command byte out to the drive. So doing fast sequential access means
]buffering your sequential file data anyhow (e.g. a simple filter

Or, if you are not performing any output operations on the serial bus,
simply do not chkin/clrchn.  I use that technique fairly often.

]program would be best off reading in 256 bytes, filtering them, then
]writing them to the output file, instead of doing
]clrchn/chkin/clrchn/chkout for each individual byte -- a 4-to-1

I once devised a very short ML copy routine for an ancient (1985?)
release of my BBS program.  It worked on a byte-by-byte basis, and was
nearly as slow as the BASIC loop it had replaced.  I use buffering
techniques constantly now (and not just for disk I/O).

]Some other trivia: Using ACPTR should be faster than using GETIN, if
]subroutine overhead is as big a problem as some hint. GETIN has to
]do all sorts of testing to see where to dispatch to -- is it keyboard,
]or is it disk? This overhead should be noticible when compared to
]LOAD, which calls ACPTR directly. But for both the IEEE drives and the
]1541, there was no significant difference between LOAD and GETIN
]times, implying that transfer speed, and not internal Kernal overhead,
]was the limitation. 

Using non-vectored Kernal calls is bad form.  The slight SLIGHT
increased overhead time is not usually noticeable, especially when
working with disk.
--
jgreco@csd4.milw.wisc.edu		Joe Greco at FidoNet 1:154/200
USnail: 9905 W Montana Ave			     PunterNet Node 30 or 31
	West Allis, WI  53227-3329	"These aren't anybody's opinions."
Voice:	414/321-6184			Data: 414/321-9287 (Happy Hacker's BBS)