Unnecessary tar-compress-uuencodes

[tp at mccall.com]

In article <1990Jul10.182546.26487 at diku.dk>, thorinn at skinfaxe.diku.dk (Lars Henrik Mathiesen) writes:
> tneff at bfmny0.BFM.COM (Tom Neff) writes:
>>[Many good reasons not to tar-compress-uuencode source and other
>>plain text in news postings.]
>>
>> * Compressed newsfeeds, which already impart whatever transmission
>>   efficiency gain LZW can offer, are circumvented and in fact
>>   sandbagged by the pre-compression of data.
> 
> 	name	       size		crummy ASCII graphics
> 	----------  -------		---------------------
> 	tar	    4718592	tar	 ------- -60.3% ------>	tar.Z
> 	tar.Z	    1874378	+37.8%				 +37.8%
> 	tar.Z.uu.Z  2229065	tar.uu.Z -------  -6.8% ------>	tar.Z.uu.Z
> 
> Of course, compression factors will vary widely; I have made this
> experiment several times, with the same picture emerging: It pays to
> compress before uuencoding, and it pays to compress after, and it pays
> best to do both.

It is true, as you show, that if you have to post uuencoded stuff, you
are better off compressing it first. That is not the issue being argued
however. The issue under discussion is whether it is better to post a shar
file or a uuencoded compressed tar file. In either case the data will be
compressed during the news feed. However, your figures above show that the
compressed tar file is smaller than the compressed uuencoded compressed tar
file. 

If we assume that a tar file is about the same size as a shar file, your
figures show that posting uuencoded compressed tar files uses MORE bandwith
than posting a shar.

I KNOW that this is a whopper of an assumption, but I don't have a shar
program and my tar writer is a royal pain to use. If someone would take a
large amount of source code (like if you happen to have rn or nn or B news
lying around) and do the following:

1) shar it and compress it and add up the sizes of all the compressed
parts.

2) tar it, compress it, uuencode it, and compress it again and check the
size.

If the result of (1) is less than the result of (2), then in addition to
all the other reasons not to post uuencoded compressed tars, we will find
that it ALSO uses more net bandwidth, and thus has NO redeeming features
(assuming all ascii text data). If, on the other hand, the result of (2) is
less than the result of (1), we will find that there is a redeeming
feature, but I will still contend that it is a pain in the rear to receive
postings in this format.
-- 
Terry Poot <tp at mccall.com>                The McCall Pattern Company
(uucp: ...!rutgers!ksuvax1!mccall!tp)     615 McCall Road
(800)255-2762, in KS (913)776-4041        Manhattan, KS 66502, USA