Comparing libraries for archiving in .Net

Recently, for my project I needed a library for archiving. About half a year ago, I used the zlibnet library for work and the impressions were not very pleasant, so I decided to look for an alternative. After a brief search, I came across a review of libraries for archiving , which led me to write this review.

Members

I will test four libraries: ZLibNet , #ZipLib , DotNetZip and ZipStorer . Now about each detail:

ZLibNet

License: Free
Size: 35 kb + 137 kb (zlib)
This library is a wrapper over the well-known library library ZLib. Since most part is unmanaged code, the authors promise high performance.
Sample code for archiving:

Zipper zip = new Zipper();
zip.ItemList.Add(inPath);
zip.ZipFile = outPath;
zip.PathInZip = enPathInZip.None;
zip.Zip();

#ZipLib

License: Modified by the GPL. Can be used in commercial projects
Size: 196 kB
The library is completely written in C #. Declared support in the same GZip, Tar, BZip2 formats.
Sample code for archiving:

using (ZipOutputStream s = new ZipOutputStream( File .Create(outPath)))
{
s.UseZip64 = UseZip64.Off;
if (level != -1)
s.SetLevel(level);

byte [] buffer = new byte [4096];
ZipEntry entry = new ZipEntry(Path.GetFileName(inPath));
s.PutNextEntry(entry);
using ( FileStream fs = File .OpenRead(inPath))
{
int sourceBytes;
do
{
sourceBytes = fs.Read(buffer, 0, buffer.Length);
s.Write(buffer, 0, sourceBytes);
}
while (sourceBytes > 0);
}
s.Finish();
s.Close();
}

Dotnetzip

License: Ms-Pl
Size: 277 kb (trimmed version)
The library is positioned as the most convenient for use in .net and mono projects. Declared support for AES encryption. The availability of many versions can also be useful: a full, reduced version (the main functionality was left and the size was significantly reduced), for the framework framework, for SilverLight. There are also separate versions that support bzip2 and a wrapper on ZLib.
Sample code for archiving:

using (ZipFile zip = new ZipFile())
{
zip.CompressionLevel = compressionLevel;
ZipEntry ze = zip.AddFile(inPath, "" );
zip.Save(outPath);
}

ZipStorer

License: Ms-Pl
Size: 33 kb (source)
Strictly speaking, it is not a library, but a separate class, in consequence of which it is extremely easy to integrate into the project, and it will be easy to make changes in which case. The possibilities are extremely limited, but given the size, you can close your eyes to this. The old version can work in Silverlight .
Here is a brief and all that can be said about the subjects.
Sample code for archiving:

ZipStorer zip = ZipStorer.Create(outPath, "About" );
zip.AddFile(compressionLevel, inPath, inputFileName, "" );
// Updates and closes the zip file
zip.Close();

Testing

Testing will be conducted as follows: 100 runs of each method are done, time is measured, 20 worst and 20 best times are removed, the average is calculated for the rest. Platform: the main tests were conducted on an E8400 (3.0GHz) processor with four gigabytes of DDRII memory. All four libraries are tested in one program, which logs all its actions and writes the results to a csv file, which can then be easily opened in the table editor. IDE - VS2010. Used. Net 4.0.
')

Archiving

The tests will be conducted on 3 files: the first is a large text file, the second is the SQLite database, and the third is the book “History of the Russian State” by Karamzin in pdf format.
For each file, two tests are performed. At first, all libraries with settings that provide maximum performance will be tested, the second will include maximum compression, unfortunately the function of the compression level is supported only by #ZipLib and DotNetZip, so only they will participate in the second stage.

Txt file

This is a text file with a size of 9,373,180 bytes. The document on the structure - the logs of correspondence on ICQ from qip.
So, the results with the maximum speed:



So, in terms of speed, #ZipLib and zlibnet are the same, however, the second library shows far better results. The remaining libraries show a serious lag in speed. Now the test results for maximum compression:



Here the results are more even.

DB file.

Database size is 19,407,754 bytes. The contents of the database - a large number of lines.



The situation is identical to the text file, now the results of the test for maximum compression:



And again the results of the first tests are repeated: one library is slightly faster, the other compresses a little better.

PDF file.

PDF with scanned pages, the size of 19,407,754 bytes. It can be expected that the compression of a special sense will not give, however, let's check it:



The gaps in size turned out to be insignificant, but the speed differs very significantly. This time in the leaders of ZipStorer, which is understandable - it has the worst compression. DotNetZip and #ZipLib show almost identical results. Now the test results for maximum compression:



The situation has changed slightly, except that the time difference slightly increased.
It is worth noting that initially the file name contained Cyrillic and only ZipStorer coped with it adequately (for this it was necessary to add a line: zip.EncodeUTF8 = true), ZlibNet refused to work with it at all (it threw out an exception in which only ASCII characters in the name were supported) , and #ZipLib and DotNetZip packed strangely: the standard windows viewer showed an empty archive. Unpacking gave the source file, but in the title all Cyrillic characters were replaced.

Unzip.

First, I checked all the archives for reading. All libraries can open archives created by other libraries, no surprises have arisen.
Immediately, the unzipping itself will be tested on two archives: the first is the base of the first test packed in the fastest way, the second is the same file, but with ultra compression. Both archives are obtained using 7-zip. Consider the results:



Paradoxically, but true: all libraries unpacked the archive with maximum compression faster than the minimum. Gigantic gaps between libraries are also surprising.

Comparison of processors.

Now I’ll run the test for archiving the test file on two more computers. The first is the one-year-old i7-870 (2.93GHz) 16Gb, and the second is the Dell 1525 T2370 (1.73GHz) 2Gb three-year laptop.
Database Archiving:



The results are amazing. Significant growth showed only DotNetZip. ZlibNet and ZipStorer showed a twofold increase in performance when switching from a laptop to a dual-core processor, but now they haven't made a significant increase in 4x, i.e. it can be concluded that they depend on the frequency rather than on the number of cores. But the most striking is the result of #ZipLib - on i7-870, compression takes longer than on the old notebook processor. I find it difficult to explain this difference.
But the results of unpacking the archive:



Here the situation is also unusual: both #ZipLib and DotNetZip on i7-870 are slower than on E8400.
Finally, I’ll provide screenshots of the Task Manager while the application is running:



Here red is the period of work of ZLibNet, blue - #ZipLib, yellow - DotNetZip, and purple - ZipStorer. It is clearly seen that DotNetZip loads both cores to the fullest. This confirms the results of the comparison test.

Results

The tests were mixed. Each of the libraries has its pros and cons. Personally, I chose DotNetZip for myself, I liked its simple interface and the predictable performance increase relative to the power of the processor.
Source code can be viewed here .