[PR #36] [MERGED] Add support for Span<byte> #61

Open
opened 2026-01-30 21:26:58 +00:00 by claunia · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/claunia/plist-cil/pull/36
Author: @qmfrederik
Created: 6/18/2018
Status: Merged
Merged: 6/19/2018
Merged by: @claunia

Base: masterHead: fixes/array-length


📝 Commits (4)

📊 Changes

5 files changed (+134 additions, -50 deletions)

View changed files

📝 .travis.yml (+1 -1)
📝 plist-cil/ASCIIPropertyListParser.cs (+28 -0)
📝 plist-cil/BinaryPropertyListParser.cs (+46 -29)
📝 plist-cil/PropertyListParser.cs (+40 -2)
📝 plist-cil/plist-cil.csproj (+19 -18)

📄 Description

We're doing a performance review of our application and are trying to make sure of the new Span<byte> and ReadOnlySpan<byte> types which are new in .NET land.

For plist-cil, working with Span<byte> opens a lot of opportunities:

  • Allowing users to read data from a subset of an byte[] array (e.g. starting at index 10 and a length of 42), without having to copy that subset to a new array (which has a performance impact)
  • Improving the performance of deserializing binary property lists.
  • ...

This PR adds support for reading property lists form those types to plist-cil.

It comes with a couple of drawbacks, though. That includes:

  • dropping support for 'old' versions of .NET Core (netstandard1.x and netcoreapp1.x). It appears there's a big push to get everyone to use at least netstandard2.0, so that should be OK
  • dropping support for .NET 4.0 (.NET 4.5 is still supported, though)
  • adding a dependency on System.Memory for the .NET Framework versions

Supporting .NET Framework without adding a dependency on System.Memory and still adding support for Span<byte> would mean duplicating a lot of code, and I'm not sure it's worth it.

Would this be a problem for you?


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/claunia/plist-cil/pull/36 **Author:** [@qmfrederik](https://github.com/qmfrederik) **Created:** 6/18/2018 **Status:** ✅ Merged **Merged:** 6/19/2018 **Merged by:** [@claunia](https://github.com/claunia) **Base:** `master` ← **Head:** `fixes/array-length` --- ### 📝 Commits (4) - [`64c9f13`](https://github.com/claunia/plist-cil/commit/64c9f134ba29f45e48bf7821c9858b0090f44e77) Add support for Span<byte> - [`3df861e`](https://github.com/claunia/plist-cil/commit/3df861eb9dbae52be1899f894f5cd9736aae54c5) Bump Travis version - [`c82174f`](https://github.com/claunia/plist-cil/commit/c82174fc6ac7f84b003701916556369a8f4f3e51) Bring back netstandard1.x - [`33542f4`](https://github.com/claunia/plist-cil/commit/33542f474653e4435a4f6c1ebcefe91eb52f4a7a) Bring back netcoreapp1.0 ### 📊 Changes **5 files changed** (+134 additions, -50 deletions) <details> <summary>View changed files</summary> 📝 `.travis.yml` (+1 -1) 📝 `plist-cil/ASCIIPropertyListParser.cs` (+28 -0) 📝 `plist-cil/BinaryPropertyListParser.cs` (+46 -29) 📝 `plist-cil/PropertyListParser.cs` (+40 -2) 📝 `plist-cil/plist-cil.csproj` (+19 -18) </details> ### 📄 Description We're doing a performance review of our application and are trying to make sure of the new `Span<byte>` and `ReadOnlySpan<byte>` types which are new in .NET land. For plist-cil, working with `Span<byte>` opens a lot of opportunities: - Allowing users to read data from a subset of an `byte[]` array (e.g. starting at index 10 and a length of 42), without having to copy that subset to a new array (which has a performance impact) - Improving the performance of deserializing binary property lists. - ... This PR adds support for reading property lists form those types to plist-cil. It comes with a couple of drawbacks, though. That includes: - dropping support for 'old' versions of .NET Core (`netstandard1.x` and `netcoreapp1.x`). It appears there's a big push to get everyone to use at least `netstandard2.0`, so that should be OK - dropping support for .NET 4.0 (.NET 4.5 is still supported, though) - adding a dependency on System.Memory for the .NET Framework versions Supporting .NET Framework without adding a dependency on System.Memory and still adding support for `Span<byte>` would mean duplicating a lot of code, and I'm not sure it's worth it. Would this be a problem for you? --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
claunia added the pull-request label 2026-01-30 21:26:58 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: claunia/plist-cil#61