Internalize or remove Zlib implementation

[eerhardt]

We have public Zlib types. We should at least make them internal, and remove them if possible.

machinelearning/src/Microsoft.ML.Data/DataLoadSave/Binary/Zlib/ZDeflateStream.cs

Line 10 in 0c62e30

public sealed class ZDeflateStream : Stream

[eerhardt]

@TomFinley - do you think we can remove this code altogether? I tried to find callers of it, but I couldn't see exactly who invokes it.

[Ivanidzo4ka]

I can be wrong, but I think we decided to go with C# inflate/deflate algorithm, because our internal zlib is actually modified version of zlib code which is impossible to open source.
It should be safe to remove all zlib code and references from this repo.

[TomFinley]

It's been some months since the evaluation, but when we did I believe we found that while compression of just raw zlib was considerably faster than what was in System.IO.Compression, decompression (which is far more important) was not that far off. And I think I opined at the time that if fast compression/decompression speeds was actually the primary goal we may as well use something more advanced than zlib anyway. So yes, from my perspective may as well remove. (But, this was a long time ago, and I think it was around the same time I performed an, um, practical demonstration of the phrase "bus number." :) So, I may not remember the circumstances perfectly.)

[danmoseley]

System.Io .Compression these days is implemented around Zlib these days : corefx has a copy of it. One would hope it is possible to get performance close to directly calling zlib, but I don't know.

[TomFinley]

x has a copy of it. One would hope it is possible to get performance close to directly calling zlib, but I don't know.

So I would have hoped too. Indeed, back when .NET Framework 4.5 was shipped, strange as it may seem the thing I was most looking forward to was that they were changing from their own internal implementation of DEFLATE, to actually using zlib. It was a definite improvement -- the pre-4.5 situation was just flat out awful -- but still to my disappointment considerably slower, by about 4x IIRC. Very disappointing. Now then, the situation now is a lot better, still a bit slower though at least on compression, at least, if I remember the evaluation we did earlier this year all right.