Some additional test-info on @Orwellophile code using a 17.9MB textfile.
Using the property values in the code-example "as is" will have a HUGE negative impact on performance, it takes 14.16 sec.
Setting the properties to the following do the same job at 3.91 sec (i.a. the archive will have the same container info which is: you can extract and test the archive with 7zip but there are no filename information)
Native 7zip 2 sec.
CoderPropID[] propIDs = {
//CoderPropID.DictionarySize,
//CoderPropID.PosStateBits,
//CoderPropID.LitContextBits,
//CoderPropID.LitPosBits,
//CoderPropID.Algorithm,
//CoderPropID.NumFastBytes,
//CoderPropID.MatchFinder,
CoderPropID.EndMarker
};
object[] properties = {
//(Int32)(dictionary),
//(Int32)(posStateBits),
//(Int32)(litContextBits),
//(Int32)(litPosBits),
//(Int32)(algorithm),
//(Int32)(numFastBytes),
//mf,
eos
};
I did another test using native 7zip and a 1,2GB SQL backup file (.bak)
7zip (maximum compression): 1 minute
LZMA SDK (@Orwellophile with above property-setting): 12:26 min :-(
Outputfile roughly same size.
So I guess I'll myself will use a solution based on the c/c++ engine, i.a. either call the 7zip executable from c# or use squid-box/SevenZipSharp, which is a wrapper around the 7zip c/c++ dll file, and seems to be the newest fork of SevenZipSharp. Haven't tested the wrapper, but I hope is perform just as the native 7zip. But hopefully it will give the possibility to compress stream also which you obvious cannot if you call the exe directly. Otherwise I guess there isn't mush advantage over calling the exe. The wrapper have some additional dependencies so it will not make your published project "cleaner".
By the way it seems the .Net Core team consider implementing LZMA in the system.io class in .Core ver. 5, that would be great!
(I know this is kind of a comment and not an answer but to be able to provide the code snippet it couldn't be a comment)