Click here to Skip to main content
15,888,401 members
Articles / Programming Languages / C#
Article

Pure C# MiniLZO port

Rate me:
Please Sign up or sign in to vote.
4.88/5 (21 votes)
22 Dec 20061 min read 140.8K   1.6K   53   44
Fast stream compression using a ported minilzo for .NET.

Introduction

I was recently in a position where I needed to find a fast streamable compression solution.  The great source by Markus Oberhumer provided the answer. After using the C code for a while, I realized C#/.NET lacked a similar library, short of one I found which was commercial.

As a result, I decided to attempt a minimalistic port of MiniLZO compression and decompression into pure C#. At this point, the code uses unsafe/fixed blocks to best mimic the original minilzo implementation. A pure managed solution may be soon to follow (at the cost of speed).

The code has not been unit tested 100%, but all initial tests have been successful. If anyone finds any bugs, please report them so I may fix it. I also have not done any profiling of the speed yet, if anyone feels upto the task of comparing it against the C implementation.

Use of the code is relatively simple, here is a quick example.

Compression

C#
byte[] original = File.ReadAllBytes("...");
byte[] destination;
MiniLZO.Compress(original, out destination);

Decompression

C#
byte[] destination = ...; /* Resulting buffer from above */
byte[] original = new byte[x];
MiniLZO.Decompress(destination, original);

Note that with compression, the destination buffer will be assigned and trimmed to the correct size. With decompression, the "original" buffer must be preallocated with the correct original size. Also note that my implementation removed all use of goto from the original source, and replaces certain uses with OverflowExceptions.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


Written By
Web Developer
Canada Canada
Short and simple, I'm a self contracted programmer, my strongest programming skills are in C/C++ and C#/.NET. I have a nack for porting C algorithms to C#.

Comments and Discussions

 
GeneralAnother such library... Pin
omaurice6-Nov-06 15:06
omaurice6-Nov-06 15:06 
GeneralRe: Another such library... Pin
Astaelan6-Nov-06 17:04
Astaelan6-Nov-06 17:04 
GeneralRe: Another such library... Pin
Ri Qen-Sin22-Dec-06 12:40
Ri Qen-Sin22-Dec-06 12:40 
GeneralRe: Another such library... Pin
omaurice22-Dec-06 12:43
omaurice22-Dec-06 12:43 
GeneralRe: Another such library... Pin
Ri Qen-Sin22-Dec-06 12:51
Ri Qen-Sin22-Dec-06 12:51 
GeneralRe: Another such library... Pin
omaurice22-Dec-06 13:00
omaurice22-Dec-06 13:00 
GeneralRe: Another such library... Pin
Astaelan23-Dec-06 4:10
Astaelan23-Dec-06 4:10 
GeneralRe: Another such library... Pin
omaurice23-Dec-06 4:32
omaurice23-Dec-06 4:32 
The numbers indeed indicate that LZO is faster on the whole. however :
1. As you indicated, QuickLZ is faster than both, by a lot. Indeed it's new, but has potential.
2. In some of the compression cases, LZF is faster than LZO (exe file, BMP, divx), and as the averaging is done based on the files' size, I could have chosen a bigger DivX file, and hence "lzf would win". What I'm trying to say is that the advantage depends on what you're trying to compress.
3. Normalizing by memcpy is not quite as invalid as you try to make it look, though I admit I did it out of laziness, not out of true belief it's 100% accurate. What I compressed in an AVI file (almost uncompressible), and my results resemble the ones in QuickLZ's tables, so the accuracy is better than I expected.

Anyway, about QuickLZ, I looked at the code, and it looks a lot more complicated than LZO/LZF, so I for one will not be porting it. Also, the speed there, while faster, isn't enough to make me want to put the effort.
GeneralRe: Another such library... Pin
Astaelan23-Dec-06 4:46
Astaelan23-Dec-06 4:46 
GeneralRe: Another such library... Pin
WorldNomad23-Dec-06 3:32
WorldNomad23-Dec-06 3:32 
GeneralRe: Another such library... Pin
omaurice23-Dec-06 4:00
omaurice23-Dec-06 4:00 
Generalwhy not adding the original size to the header of the buffer Pin
Huisheng Chen5-Nov-06 15:19
Huisheng Chen5-Nov-06 15:19 
GeneralRe: why not adding the original size to the header of the buffer Pin
Astaelan6-Nov-06 17:01
Astaelan6-Nov-06 17:01 
GeneralRe: why not adding the original size to the header of the buffer Pin
SimmoTech6-Nov-06 20:44
SimmoTech6-Nov-06 20:44 
GeneralRe: why not adding the original size to the header of the buffer Pin
Astaelan6-Nov-06 21:12
Astaelan6-Nov-06 21:12 
GeneralImpressive, but... Pin
woudwijk4-Nov-06 1:11
woudwijk4-Nov-06 1:11 
GeneralRe: Impressive, but... Pin
Astaelan4-Nov-06 10:29
Astaelan4-Nov-06 10:29 
GeneralAgreement Pin
Ri Qen-Sin22-Dec-06 12:44
Ri Qen-Sin22-Dec-06 12:44 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.