Compaction Algorithm (pack vs compress)

wrs at pupthy.UUCP wrs at pupthy.UUCP
Sun Mar 2 03:43:31 AEST 1986


In article <226 at uvacs.UUCP> rwl at uvacs.UUCP (Ray Lubinsky) writes:

(On the relative merits of pack/compact/compress...)

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

The above comments are pretty much true.  Since disk space is allocated in
integral block chunks, reducing the size of a file below the minimal disk
storage size does nothing much for you.  I.E. a 2056 byte file and its packed
1378 byte (say) compressed version both take 2k of physical disk space.  
(Although why you would want to compress a 2k file for other than test purposes,
I don't know.)

However, if the file size is sufficiently large, the "file blocking" becomes
pretty much irrelevant.  We have been using compress to reduce the size of some
of our data file, which have had sizes up to 100Mb (Yes, Mega-bytes!)

Tests run on our Ridge (disk blocks = 4k) gave the following results:

3Mb data file (text):

    Original:	3956579b ==> 966 blocks
    Compress:	 759914b ==> 186 blocks = 81% compression	 157.0 cpu sec
    Compact:	2002303b ==> 489 blocks = 49% compression	1452.0 cpu sec
    Pack:	1998736b ==> 488 blocks = 49% compression	  98.7 cpu sec

100kb executable (stripped):

    Original:	 186960b ==>  46 blocks	
    Compress:	  87005b ==>  22 blocks = 52% compression	   9.5 cpu sec
    Compact:	 126561b ==>  31 blocks = 33% compression	  88.5 cpu sec
    Pack:	 126437b ==>  31 blocks = 33% compression	   4.9 cpu sec

(I would have tried one of our 100Mb files, but didn't have one around)

------------------------------------------------------------------------
William R. Somsky                          Physics Dept ; Princeton Univ
{ihnp4,princeton}!pupthy!wrs             PO Box 708 ; Princeton NJ 08544



More information about the Comp.unix mailing list