Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!um-math!hyc
From: hyc@math.lsa.umich.edu (Howard Chu)
Newsgroups: comp.sys.atari.st
Subject: Re: using memory (was re: A REAL RamDisk)
Message-ID: <633@stag.math.lsa.umich.edu>
Date: 4 May 89 00:05:04 GMT
References: <892@a.lanl.gov> <3694@nunki.usc.edu> <1477@atari.UUCP>
Sender: usenet@math.lsa.umich.edu
Reply-To: hyc@math.lsa.umich.edu (Howard Chu)
Organization: University of Michigan Math Dept., Ann Arbor
Lines: 23
UUCP-Path: {mailrus,umix}!um-math!hyc

In article <1477@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
>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. 

Yep... Particularly for floppies, using a buffer at least the size of one
track seems to do pretty good. I set up ARC to use 30K for all its stdio
buffers, which has done pretty well. In particular, now it reads and writes
most files in only a couple disk accesses. (ARC'ing up a source tree - how
often do your individual source files exceed 60K?) Used the same approach
with KA9Q Net - FTPs are much faster now, fewer line turnaround delays...

Of course, using Mark Williams C, this required a change to the stdio
library. As distributed, it uses fixed size buffers (of 1024 bytes). If
they were *really* serious about ANSI compliance, they'd have included
setvbuf or setbuffer in the library from the beginning...
--
 -=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1]
 and You Too can have a Personal Electronic Relationship with God!