search

icsharpcode / SharpZipLib

#ziplib is a Zip, GZip, Tar and BZip2 library written entirely in C# for the .NET platform.
http://icsharpcode.github.io/SharpZipLib/
MIT License
3.7k stars 976 forks source link

Checksum Support for ReadOnlySpan<byte> #841

Open ds5678 opened 1 year ago

ds5678 commented 1 year ago

I added support for hashing byte spans. The only breaking change in my pull request is adding IChecksum.Update(ReadOnlySpan<byte>).

I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.

lahma commented 1 year ago

Just a thought, as this is anyway breaking the interface and requiring new implementation. Would it make sense to only support Update(ReadOnlySpan<byte> buffer) and change this in new version (1.5?). This interface looks like something that not many rely upon directly.

ds5678 commented 1 year ago

The interface is unimportant to me. I only changed it for completeness. Whatever the maintainers want is ok with me.

If breaking changes were being fully embraced, I would remove the array and array segment overloads. I assumed that binary compatibility was important to maintain, so I did not remove those.

lahma commented 1 year ago

Yes, it's maintainer's call, I think it already fails binary compatibility by adding a new method that old implementations don't implement.

ds5678 commented 1 year ago

I think it already fails binary compatibility by adding a new method that old implementations don't implement.

This is true, and I said as such in my initial message, but it's a much smaller breaking change than removing a bunch of redundant methods.

piksel commented 1 year ago

Yeah, avoiding breaking changes is one of the guiding principles for maintaining the library, and this PR currently lacks the motivation for the change.

It should be a fairly exotic use case for a consumer to implement their own CRC, so I think a breaking change could be acceptable here, but there needs to be a reason for doing so.

ds5678 commented 1 year ago

Motivation for the overall PR

It enables library users to reduce their allocations, resulting in significant performance gains.

Motivation for adding a span overload to the interface

Anyone not using the checksum classes directly, will not benefit from the performance gains of using spans.

Motivation for removing the redundant overloads

It simplifies the codebase and is a source-compatible change. If spans had been always been supported, these overloads would have never existed.

ds5678 commented 10 months ago

@piksel What do you want me to do?