wizard@sosaria.imp.com (Chris Brand) (08/16/90)
After making a full backup using bru I found that it's not that good as I first thought - at least for me. On my harddisk, every binary file bigger than 10K is crunched, giving me about twice as much room for binary files than without crunching anything. If you compress crunched files, inclulding archives made with zip or lharc, they get bigger than before. Example: I have a lzh file with 850K. If I compress it using BRU's Huffman encoding with 16 bits, it takes me afterwards over 1000K. BRU doesn't check if the compressed file is larger than the original and stores only the compressed version. With this unlogical behaviour of BRU, I gain nearly no disks compared to Quarterback, and the latter is nearly twice as fast. So - if you have lots of crunched files, archives, pictures, anims and so on on your harddisk, don't use BRU. It doesn't pay off. Stick with Quarterback. -- ------------------------------------ Chris Brand - wizard@sosaria.imp.com "Justice is the possession and doing of what one is entitled to" - Platon ------------------------------------
bobl@pro-graphics.cts.com (Bob Lindabury) (08/18/90)
In-Reply-To: message from wizard@sosaria.imp.com > afterwards over 1000K. BRU doesn't check if the compressed file is larger > than the original and stores only the compressed version. With this > unlogical behaviour of BRU, I gain nearly no disks compared to Quarterback, > and the latter is nearly twice as fast. So - if you have lots of crunched > files, archives, pictures, anims and so on on your harddisk, don't use BRU. > It doesn't pay off. Stick with Quarterback. Doesn't it make more sense just to turn OFF the compression in BRU? Seems to me that BRU has some features that Quarterback doesn't (SCSI Tape Support) and it does have a Shell written for it called "BRUShell" that has a point and click interface. -- Bob >From pro-graphics!bobl Fri Aug 17 20:05:27 1990 Date: Fri, 17 Aug 90 20:05:02 EDT Ppath: pro-exchange!pro-sol!pro-lep!syslep From: bobl@pro-graphics.cts.com (Bob Lindabury) Message-Id: <331.proline/net@pro-graphics> To: syslep@pro-lep Subject: Re: Quarterly Posting [of modification listing] In-Reply-To: message from syslep@pro-lep.cts.com Thank you, thank you, thank you! Jezz..I was getting very depressed about this listing and the hours I spend verifying modifications, repacking them into easy unparable files and even writing manuals for some of them and then shrinking them (and soon to BINSCII them) not to mention keeping track of revisions and the database. Seems just a few vocal people with "Don't do this" attitudes prevail in most cases. I have received a few responses in favor of the quarterly "full" listing and that has helped. I was about this " " close to just discontinuing the proline mods archives and saying the heck with it. Your support has made me feel a bit better. Be prepared for a lengthy rebuttal from Rich (Self Appointed Net Traffic Watcher) soon. <grin> -- Bob PS: The transfer time came in at 3 minutes over AT&T. Reachout America clocks in at $6.70 per hour and the cost per message is $.33. That's $1.32 for the whole year. I think the Modification Listing and Archives are worth $1.32 per year..don't you? And Morgan (who seems to be on the "other" side has requested items from the archives himself...and it was just after I posted the listing...hmmm. ________ Pro-Graphics BBS - It's better than a sharp stick in the eye! ________ InterNet: bobl@pro-graphics.cts.com | Pro-Graphics: 908/469-0049 UUCP: ..crash!pro-graphics!bobl | CServe: 70347,2344 ARPA/DDN: ..crash!pro-graphics!bobl@nosc.mil | Amer. Online: Graphics3D ___________ ____________ Raven Enterprises - 25 Raven Ave. Piscataway, NJ 08854
fnf@riscokid.UUCP (Fred Fish) (08/22/90)
In article <03880.AA03880@sosaria.imp.com> wizard@sosaria.imp.com (Chris Brand) writes: >On my harddisk, every binary file bigger than 10K is crunched, giving me >about twice as much room for binary files than without crunching anything. >If you compress crunched files, inclulding archives made with zip or lharc, >they get bigger than before. Example: I have a lzh file with 850K. If I >compress it using BRU's Huffman encoding with 16 bits, it takes me >afterwards over 1000K. BRU does not use Huffman, it uses the standard LZW compression algorithm, defaulting to 12 bits, but able to use up to 16 bits if you request it with the -N flag. You are correct in that most compressed files will get bigger when compressed again. >BRU doesn't check if the compressed file is larger >than the original and stores only the compressed version. With this >unlogical behaviour of BRU, I gain nearly no disks compared to Quarterback, This is incorrect. BRU checks that the final compressed version is no larger than the original, and saves either the compressed version or the original as appropriate. When run with -vvvv it will report which files are saved uncompressed. The "growth factor" you are seeing is the BRU archive overhead. A summary of this overhead is: 1) 12.5% for the block headers on each 2K archive block. The block header is 256 bytes, and contains lots of information bru uses to keep track of each archive block. 2) Each archived file requires one 2k file header block and then an arbitrary number of data blocks, each 2k. Thus a zero length file consumes 2k of archive space. A 1 byte file consumes 4k (2k header + 1 data block). 3) The archive has a 2k archive header block and a 2k archive trailer block. Thus approximately 1000K of archive space to store a 850K file sounds about right. The overhead takes an even bigger bite for groups of small files, because of the file header block. The archive format was designed for robustness and expandability, with compactness only a secondary concern. In retrospect, it would probably have been better to pay more attention to space considerations and make the archive format a pure stream format with blocking done by the I/O routines. Maybe in BRU II ... -Fred