Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!portal!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: using memory (was re: A REAL RamDisk)
Message-ID: <1477@atari.UUCP>
Date: 3 May 89 00:24:52 GMT
References: <892@a.lanl.gov> <3694@nunki.usc.edu>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 34

In article <3694@nunki.usc.edu> rjung@sal61.usc.edu (Robert  allen Jung) writes:
> You're
> uncompressing a package, and send all of the bits into the RAMdisk. 

Solutions like this are necessary because of problems like ARC.  ARC is
poorly implemented in that it reads & writes 512 or 1024 bytes at a time
(as far as I know).  You get HUGELY improved throughput if you read a
large buffer-full of your source, decode into another buffer, and write
large chunks at a time.  The chunks don't have to be very big: you get
dramatic improvements at 16K, and usually not much increased benefit by
going up to 1M or more. 

Look how much faster UNARC.TTP is than the equivalent extraction using
ARC.  The entire difference is that UNARC reads the file in from the
archive, uncompresses it, then writes the plaintext.  It might not even
read & write the whole thing, and I don't care; it's a hell of a lot
more than 1024 bytes!

The extreme example of this problem is GFA BASIC, which reads and writes
text files ONE BYTE AT A TIME.  That is, they use

	Fread(fd,1L,&c);

to read a character from a file.  This is ABSURDLY slow, and you end up
with whole subcultures coming up with workarounds to make text file I/O 
reasonably fast.

I know this doesn't directly address the RAMDISK problem; that's been
put to bed, I think (can't resize meaningfully under TOS).  My point is
this: you have lots of memory; use it!

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt