-1

I am using compression in my winform application to compress files before uploading. Previously we used .net framework 3.5 and the GZipStream class in that produced larger sized files in most of the cases.But, after upgrading to .net framework 4.5, I get really good compression results for same set of files.So, it seems they have fixed the compression bug in .net 4.5 . But I want to know if there are still some scenarios where the GZip compression will produce files of larger size than the original file.If the the file size remains the same then that is not a problem. Or shall I consider using some other compression, I also tried Donetzip Lib.But, the .net 4.5 GzipStream is giving me better results.

V K
  • 1,645
  • 3
  • 26
  • 57
  • 1
    Compressing a file will always have a couple of bytes of overhead for metadata. If the file you're trying to compress cannot possibly be compressed any more than it already is, then the end result will be larger than the original file. Not much you can do about that. – CodeCaster Sep 05 '16 at 09:15

1 Answers1

2

Yes. In fact it is guaranteed that any lossy compression scheme will expand some data streams, if it compresses any data streams. You can feed the compressor random data to see how much it is expanded.

The maximum expansion is bounded to a small amount. The gzip header and trailer is usually 18 bytes added to the raw deflate stream (i.e. if there is no file name, extra data, or comment in the gzip header), and the expansion of the original data in the raw deflate stream is limited to adding five bytes for each stored block. The size of a stored block depends on the compressor and the options. If NET 4.5 is using zlib with the default options, then the block size is 16383 bytes. You add five bytes for the last block as well, which may be less than 16383 bytes.

So, for example, if you are compressing 20,000 random bytes to the gzip format with zlib using the default settings, then the resulting size is 20,028 bytes. Compressing 30 random bytes will result in a 53 byte output.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158