🚀 go-pugleaf

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!