I'm using .NET 2.0.50727 in VS 2005 Pro, ENU Service Pack 1 (KB926601). I've been experimenting with the System.IO.Compression classes GZipStream and DeflateStream, and I found it interesting to note that they'll create different-sized compressed files depending on the procedure you use to take in the source file's data. With one, almost every file I feed them for compression ends up significantly bigger. That code is below, almost verbatim per MS's MCTS Exam 70-536 self-paced training kit. Below it are some sample size results per file type.
-
static void CompressFile(string toCompress, string toBeCompressed)
-
{
-
FileStream srcFile = File.OpenRead(toCompress);
-
FileStream destFile = File.Create(toBeCompressed);
-
GZipStream compStream = new GZipStream(destFile, CompressionMode.Compress);
-
int lilByte = srcFile.ReadByte();
-
while (lilByte != -1)
-
{
-
compStream.WriteByte((byte)lilByte);
-
lilByte = srcFile.ReadByte();
-
}
-
-
compStream.Close();
-
srcFile.Close();
-
destFile.Close();
-
-
//Sample Results, GZipStream/DeflateStream:
-
//Text document: 1.98K --> 1.79K/1.77K
-
//Word document: 140K --> 227K
-
//Bitmap: 123K --> 168K
-
//PDF document: 248K --> 347K/346K
-
}
-
This code, however, performed much better:
-
static void CompressBetter(string toCompress, string toBeCompressed)
-
{
-
byte[] fileBytes = File.ReadAllBytes(toCompress);
-
FileStream destFile = File.Create(toBeCompressed);
-
GZipStream compStream = new GZipStream(destFile, CompressionMode.Compress);
-
compStream.Write(fileBytes, 0, fileBytes.Length);
-
-
compStream.Close();
-
destFile.Close();
-
-
//Sample Results, both:
-
//Text document: 1.98K --> 1.28K
-
//Word document: 140K --> 21.6K
-
//Bitmap: 123K --> 20.6K
-
//PDF document: 248K --> 301K (Well, I guess they can't all work)
-
}
-
Perhaps these classes like having more to work with up front? Anyone else have any opinions/observations?
