euloth@dalcsug.UUCP (George Seto) (07/23/88)
Here is a copy of a message I found on a New York BBS :
From: FORSTER@cs.u
EVALUATION OF ARC, DISK COMM, AND ALFCRUNCH
by
Marty Albert
June 9, 1988
Well, here we go again. Another comparison of file compression
systems for the Atari 8-Bit Computers. Frankly, the way things look
from here, this may very well be the last such comparison done by me.
(what's that? cheering?!?)
This time, I've taken a look at ARC/ARCX 1.2, Disk Comm 3.2, and the
new AlfCrunch 1.2 that has just started showing up. I've taken a very
close look at them in fact, and I had more than a few surprises!
First, let's see the test data, them my own editorial comments.
Test Setup
All tests were done on the following system:
256K 800XL
1-1050 with US Doubler
1-meg MIO
SpartaDOS 3.2d
All of the source files were on the 1050 and the compacted files were
written to the MIO RAM-Disk during creation. For recovery, the
compacted files were on the MIO and the recovered files were written
to the 1050.
In all cases, the high speed option was enabled.
In all cases, the computer was re-booted to get rid of all excess
memory use between each creation and recovery.
Recovery was always to a freshly formatted disk.
The files use as source files were:
SAVEd BASIC ------- 12078 bytes
Binary Load ------- 13054 bytes
Compiled T-BASIC -- 11877 bytes
ASCII Text -------- 8740 bytes
Atari Font -------- 1024 bytes
Virtuoso Show ----- 6528 bytes
MI Picture -------- 7684 bytes
Daisy-Dot Font ---- 2307 bytes
KOALA Picture ----- 1881 bytes
RLE Picture ------- 6550 bytes
------
TOTAL 71723 bytes
All byte counts were based on the numbers provided by the SpartaDOS
3.2d directory listing.
Times were kept with a stop-watch and are as accurate as possible.
Allow a +/- 3 seconds to the times.
On ARC/ARCX and on AlfCrunch, the screen was OFF to speed up the
processing. They were also run from a SpartaDOS BATch file and/or the
command line input feature.
On Disk Comm, the entire 256K of the 800XL was used.
Test Results
The following chart is the results that I got with the test:
PROGRAM TTM TTR SIZE % CHANGE ERRORS
-----------------------------------------------------------
ARC 7:01 6:07 55630 -22.44% none
AlfCrunch 1:37 0:57 50541 -29.53% none
Disk Comm 3:53 1:36 66416 - 7.40% none
Evaluation of Tests
ARC/ARCX
Well, no big surprise here. ARC is slow, but does a wonderful job of
compression. The compression of the files is not really all that big
a deal for the local BBS, but for an on-line pay service like GEnie or
CompuServe, that can be *very* important! Again, I failed to get the
damage to the recovered files that has been so often reported. But,
this is all old news.
Disk Comm
Again, nothing much different here, either. Disk Comm is much faster
than ARC, but doesn't do much in the way of compaction. For the
occasional boot disk, Disk Comm is probably the best way to go, but
more on that later in my editorial comments.
AlfCrunch
All I can say is WOW! I've always said to those that don't like ARC
that as soon as something better comes along, I'll go for it. Well,
here it is! Not only is AlfCrunch faster than ARC/ARCX, it's *faster*
than Disk Comm! And, to sort of add insult to injury for Disk Comm,
AlfCrunch even compresses *better* than ARC!
After I saw the above results, I went back and used AlfCrunch on many
more files, 40 all told, and did not not get a single damaged file. I
tried all sorts of files ranging from long BASIC XE programs to tiny
little data files. They all worked fine after being processed and
recovered.
It looks very good, but again, more on that later.
Editorial Comments
DISCLAIMER
The comments here are my own. They are NOT the official position of
anyone or anything except myself, nor should they be read as anything
but opinion based on the above tests.
I've always liked ARC. It may be slow, but it's good. Perhaps that's
because as a SysOp on GEnie, I'm more aware of the costs in dollars
for downloading big files.
I also like Disk Comm. It's easy to use, reliable, and fast. It also
does at least a little compaction, which is more than can be said for
the other boot disk systems. I've never been happy with the light
compaction, though, and I still think that a better way can be had.
So, along comes AlfCrunch. At first, I thought it to be just another
cute toy that someone had done. Was I ever wrong! When I ran the
tests (by the way, AlfCrunch was the last one I tested), I was shocked
by the speed. As you can see, AlfCrunch is far faster than Disk Comm.
At that point, I figured that the compression would be light. When I
did the directory and saw the byte count, I just knew that SpartaDOS
had just shown me some hidden bug. I tried it a few more times, with
the same results, and the file recovered into the right number and
size of files, and they all worked!
Needless to say, I was blown right out of the water!
Then came the neat part.
My ARCVIEW program works on the AlfCrunched file! I get some garbage
characters in there, but it works. I think (not sure!) that this is
due to the file header used. That remains to be seen for sure,
though.
The bottom line is this:
For boot disks, keep on using Disk Comm. It's the best that we have
right now. I'd like to see better, but who knows?
For the files that you've been ARC'ing, have a look at AlfCrunch. As
you can see, it seems to be far superior to anything else now
available.
One note about AlfCrunch. The DOCs are *very* complete, except that
the author's name/address info is skimpy. What shows up in the DOCs
is:
Alfred
Programmer's Aid BBS
(416) 465-4182
I'd like to know just who this guy is!
So, Alfred, if you're reading this, let us know who you are!
Marty Albert
GEnie Atari 8-Bit RT SysOp
GEnie Mail address --- MARTY.A
Suite 6-216
Box 4005
Carmichael, CA
95609-4005
--
*******************************************************************************
* euloth@dalcsug.uucp || Disclaimer: All opinions are my own unless other- *
* /\/\/\/\/\/\/\/\/\/\ || wise noted. *
****AKA: Atari Nut*************************************************************