Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site uvacs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!mcnc!ncsu!uvacs!rwl
From: rwl@uvacs.UUCP (Ray Lubinsky)
Newsgroups: net.lang.c,net.unix
Subject: Re: Re: Compaction Algorithm (pack vs compress)
Message-ID: <226@uvacs.UUCP>
Date: Tue, 25-Feb-86 15:09:32 EST
Article-I.D.: uvacs.226
Posted: Tue Feb 25 15:09:32 1986
Date-Received: Sat, 1-Mar-86 17:50:45 EST
References: <207@pierce.UUCP> <3261@sun.uucp>
Organization: U.Va. CS in Charlottesville VA
Lines: 41
Xref: watmath net.lang.c:8011 net.unix:7231

> > I am in need of a packing algorithm which works better than the
> > PACK Utility of UNIX.  I have also looked at COMPRESS ( developed
> > at University of Utah ).  COMPRESS works great if distinct number
> > of input bytes is small.  But if the distinct input bytes reach
> > 256 ( binary data ), PACK works better than COMPRESS.  With PACK
> > I am getting a saving of 20-25%.  If anybody has an algorithm
> > that would do better in packing "load modules", I would like to
> > know about it.
> 
> Are you sure you have the latest version of "compress"?  I tried "pack"ing
> and "compress"ing "/usr/bin/suntools" (which is a BMF executable image) and
> "compress" did significantly better than "pack" did (it took significantly
> more time doing it, but that's life).  Remember, Lempel-Ziv compression will
> discover frequently-occurring sequences of bytes, and unless your machine
> has all one-byte instructions you're likely to get some multi-byte sequences
> occurring frequently.
> -- 
> 	Guy Harris
> 	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
> 	guy@sun.arpa	(yes, really)

Hold on thar, Babaloo!  If you mean better in terms of *byte* savings, I
imagine ``compress'' could easily do better than ``pack''.  But if you're
talking about *block* savings, I'm dubious that ``pack'' will be much improved
upon.  I don't know about your system, but my Vax running 4.2 BSD permits
internal fragmentation, so it's disk block savings that count.

Now, I'm not entirely familiar with ``compress'', but I can compare with
``compact''.  When I created a file of 2000 bytes (one identical character
per line plus a newline), ``compress'' boasted of > 85% compression, while
pack only claimed 50% compression, but each of the results consumed the same
amount of blocks.  Hence the same effective compression.

Sqeezing a few extra bytes out of a file can only be worth it if it results in
reducing by the 1K minimum data block size (2 basic file system blocks).  Is
this often the case?  (On my system, ``pack'' runs considerably faster than
``compact'', so the choice is easy.)
-- 

Ray Lubinsky	University of Virginia, Dept. of Computer Science
		UUCP: ...!cbosgd!uvacs!rwl or ...!decvax!mcnc!ncsu!uvacs!rwl