Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: faster dos reads
Keywords: DOS, slow, real slow, deadly slow
Message-ID: <90846@sun.uucp>
Date: 22 Feb 89 23:19:39 GMT
References: <3699@ucdavis.ucdavis.edu>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Distribution: comp.sys.amiga.tech
Organization: Sun Microsystems, Mountain View
Lines: 34

In article <3699@ucdavis.ucdavis.edu> (Bruce Rogers) writes:
>	Hi, I'm looking for some information on speeding up normal
>AmigaDos reads. I've tried numerous different methods and these are the
>numbers I've gotten:
>Aztec fread: 22 secs
>Aztec fgetc: 14 secs
>AmiDos Read:  9 secs
>load program (to run) 4 secs!
>	now, what I'd like to know is how can I read the file sequentially
>at the same speed it gets loaded to run?

Well, I am pretty sure that using stdio (aka fread fgetc) is going to be
a lot slower than lower level reads (aka read) which will be slower than
the straight dos read (aka Read). The only faster way to read something
is to send the DOS packets yourself to the filesystem handler for the
file you are reading. 

>	If I can't find a way to get the loading down in the 5-10
>second range, I will probably try using the trackdisk device. Can anyone
>tell me how fast I can expect that to go?

Trackdisk will be a bit faster, but you will then have to understand the
filesystem that is on the actual disk and thus worry about hash chains,
file header blocks, file extension blocks etc. That's why you want to deal
with the file handler rather than the raw disk, because you probably can't
read the data any faster than the handler. Now the other option is to 
bypass the handler use trackdisk.device and not bother storing your data
in any sort of well known way, just dump it a track at a time on the disk.
Maybe we could get Commodore to support a "CSTM" (aka Custom) disk header
that would be simply a signal to DOS not to try to validate the disk.

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.