Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!know!daemon
From: C506634@UMCVMB.MISSOURI.EDU (Eric Edwards)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: A more memory efficient compress
Message-ID: <20740@know.pws.bull.com>
Date: 30 Jan 91 08:30:07 GMT
Sender: daemon@pws.bull.com
Lines: 44
Approved: warren@pws.bull.com

In Message-ID: <1991Jan28.190108.13993@zorch.SF-Bay.ORG>
          xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) said:
>
>If you get a file compressed by someone _else_, your best bet is to do
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     The only case I'm really interested in.....
>an uncompress, compress -b14 on your host site before transferring the
>data down, just to be on the safe side.
Not practical.  UMCVMB is not a unix box. It's as IBM 3090 170j with 7 bit dial
ups.  If I have to muck with file on the mainframe I'll uncompress it and
download the resulting text file after coverting to ebcdic..  It's faster but
still a lot of hassle.

Really though, if I have a lot of files to transfer I take the mainframe out
of the loop and ftp directly to a PC.  There's no opportunity to massage the
files first.

>Better to use the "-b12" flag than to rewrite compress to run more slowly.

Great idea Kent!  Now, how do we go about convicing all the archive operators
on the Internet to compress with "-b12"?

>As to lharc and zip, I don't know whether they inherently use smaller
>buffers than the compress default (probably, though, since both had

The point is, they achieve as good or better compression than compress with
lesser memory requirements.

>In general, your "using the same algorithm" ignores the fact that the
>compress algorithm has a scaling factor controlled by the "-b" flag,

Which is almost useless information since almost all compressed files are
done with 16 bit compression.

On a more productive note, I've made a little progress in getting compress to
run on my system.  By running nofastmem at the beginning and end of my startup-
sequence I am able to force most memory allocations into chip ram.  This leaves
a 450k block of fast ram after boot up, enough to run compress.  It doesn't
very long, though for this block to get broken up.  So, in general, I have to
reboot if I want to run compress.

Eric Edwards: c506634 @    "The 3090.  Proof that by applying state of the
Inet: umcvmb.missouri.edu   art technology to an obsolete architecture,
Bitnet: umcvmb.bitnet       one can achieve mediocre performance."