Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Hi, I'm trying to implement a LZMAInputStream class (decompressing LZMA streams) for .NET (Windows desktop) and .NET Compact framework (Windows CE) using C# without success. This class should inherit from System.IO.Stream class. To reach maximum performance I made a win32 wrapper dll (using the ANSI-C decompressing part of the SDK) which exports the LzmaDecoderInit() and the LzmaDecode() functions.
The problem is that using these functions there's no way to implement a "true" stream.
1. When _LZMA_IN_CB is defined the LzmaDecode() function is calling a callback function as soon as new input data is required. Unfortunately there's no way to call a managed method (within my LZMAInputStream class) from unmanaged code (win32 wrapper dll). So this method doesn't work.
2. When _LZMA_IN_CB is not defined you have to provide the complete compressed data to the LzmaDecode() function. As compressed files easily could be too big to fit in memory (especially under Windows CE with it's 32 mb memory limit per process) this method is unusable, too.
Similar to zlib the library, there should be a way to call the decoder function (LzmaDecode) multiple times with "fresh" input data ...
What about LZMA# SDK?
Probably I can update it to support System.IO.Stream.
Hi Igor, my experiments with the unmanaged zlib library and the managed SharpZipLib (http://www.icsharpcode.net/OpenSource/SharpZipLib/Default.aspx) showed that at least under Windows CE and the .NET Compact Framework the speed differences between managed and unmanaged code is enormous. Often the native code executes 5 to 10 times faster than the unmanaged code. That's why I would prefer the LZMA SDK.
I think an api which allows calling the compressor and the decompressor multiple times (with new input data when needed) would make the LZMA SDK much more usable. You could take a look at the zlib and libbzip2 libraries. Both libraries have a very nice api which suffice everyones requirements ...
> Often the native code executes 5 to 10 times faster than the unmanaged code. That's why I would prefer the LZMA SDK.
LZMA# provides 70% of C++ speed.
I don't like zlib API. It's too complex.
You're right, the zlib api is very complex. That's simply the price for having maximum control over the compression/decompression progress ...
Although I doubt that the unmanaged code will reach 70% of the native code on a mobile device using the Compact Framework I'll give it a try.
LZMA# SDK has benchmark. If you can check it on mobile device, write about results here.
To reduce memory usage:
LzmaBenchmark(Int32 numIterations, UInt32 dictionarySize, bool isBT4)
LzmaBenchmark(numIterations, (1 << 17), false);