Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!cuae2!ltuxa!we53!abstl!wucs!wucec2!jdz
From: jdz@wucec2.UUCP
Newsgroups: net.lang.c,net.unix
Subject: Re: Re: Compaction Algorithm (pack vs compress)
Message-ID: <1435@wucec2.UUCP>
Date: Mon, 3-Mar-86 22:28:23 EST
Article-I.D.: wucec2.1435
Posted: Mon Mar  3 22:28:23 1986
Date-Received: Fri, 7-Mar-86 06:34:05 EST
References: <207@pierce.UUCP> <3261@sun.uucp> <226@uvacs.UUCP>
Reply-To: jdz@wucec2.UUCP (Jason D. Zions)
Organization: Wash. U. Center for Engineering Computing
Lines: 46
Xref: watmath net.lang.c:8076 net.unix:7303


 >> > 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 ).

 >> 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).

 >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.
 >
 >Squeezing 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.)

Ahem. When one compresses a 2 block file, one would not expect savings of
more than one block. Can we get serious here? Compression of 2kbyte files
is a non-problem; compression of 20kb and 200kb files is. 85% of 200 blocks
gives me a savings of 170 blocks (rounding off, folks - don't flame) as
opposed to 50% which saves only 100 blocks.

When transmitting by phone, EVERY BYTE counts. When storing on tape, bytes
may count, depending on tape program. When storing on disk, blocks and frags
(for 4.2BSD) count. But you need to be considering reasonable size files before
you start talking about the lack of difference between compression tools.

Yeah, compress is slower than pack. But the phone line is slower still...

-- 
Jason D. Zions			...!{seismo,cbosgd,ihnp4}!wucs!wucec2!jdz
Box 1045 Washington University
St. Louis MO 63130  USA		(314) 889-6160
Nope, I didn't say nothing. Just random noise.