Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 11/03/84 (WLS Mods); site pupthy.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!astrovax!pupthy!wrs From: wrs@pupthy.UUCP Newsgroups: net.lang.c,net.unix Subject: Re: Re: Compaction Algorithm (pack vs compress) Message-ID: <51@pupthy.UUCP> Date: Sat, 1-Mar-86 12:43:31 EST Article-I.D.: pupthy.51 Posted: Sat Mar 1 12:43:31 1986 Date-Received: Sun, 2-Mar-86 02:45:08 EST References: <207@pierce.UUCP> <3261@sun.uucp> <226@uvacs.UUCP> Reply-To: wrs@pupthy.UUCP (William R. Somsky) Organization: Physics Dept, Princeton Univ Lines: 51 Xref: watmath net.lang.c:8026 net.unix:7259 Summary: In article <226@uvacs.UUCP> rwl@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