Consider removing unnecessary bitwise and operations

[paulomorgado]

These bitwise and operations are redundant:

• Write((byte)((i & 0xFF00) >> 8));
• Write((byte)(i & 0x00FF));
• Write((byte)((i & 0xFF00) >> 8));
• Write((byte)(i & 0x00FF));
• Write((byte)((i & 0xFF000000) >> 24));
• Write((byte)((i & 0x00FF0000) >> 16));
• Write((byte)((i & 0x0000FF00) >> 8));
• Write((byte)(i & 0x000000FF));
• Write((byte)((i & 0xFF000000) >> 24));
• Write((byte)((i & 0x00FF0000) >> 16));
• Write((byte)((i & 0x0000FF00) >> 8));
• Write((byte)(i & 0x000000FF));
• (short)(((i & 0xFF00) >> 8) | ((i & 0x00FF) << 8))
• (int)(((i & 0xFF000000) >> 24) | ((i & 0x00FF0000) >> 8) | ((i & 0x0000FF00) << 8) | ((i & 0x000000FF) << 24))
• (long)(((i & 0xFF00000000000000) >> 56) | ((i & 0x00FF000000000000) >> 40) | ((i & 0x0000FF0000000000) >> 24) | ((i & 0x000000FF00000000) >> 8) | ((i & 0x00000000FF000000) << 8) | ((i & 0x0000000000FF0000) << 24) | ((i & 0x000000000000FF00) << 40) | ((i & 0x00000000000000FF) << 56))
• (ushort)(((i & 0xFF00) >> 8) | ((i & 0x00FF) << 8))
• (uint)(((i & 0xFF000000) >> 24) | ((i & 0x00FF0000) >> 8) | ((i & 0x0000FF00) << 8) | ((i & 0x000000FF) << 24))
• (ulong)(((i & 0xFF00000000000000) >> 56) | ((i & 0x00FF000000000000) >> 40) | ((i & 0x0000FF0000000000) >> 24) | ((i & 0x000000FF00000000) >> 8) | ((i & 0x00000000FF000000) << 8) | ((i & 0x0000000000FF0000) << 24) | ((i & 0x000000000000FF00) << 40) | ((i & 0x00000000000000FF) << 56))

[lukebakken]

We should investigate using the code from this project with the appropriate fixes and accreditation.

[lukebakken]

Also see https://github.com/dotnet/corefx/issues/31265

[stebet]

I actually have an implementation that's easily usable for a proper cross-platform fix, that I used in the pipelines implementation here: #706

It utilizes functionality from System.Memory (which has targets for the needed TFMs) and would be compatible with .NET Core moving forward.

[lukebakken]

@stebet what do you think about adding those changes for the 6.0 release? It sounds reasonable to me.

[stebet]

Should be doable. That library will also enable memory pooling and is well compatible with .NET Framework targets (used in StackExchange.Redis and Google.Protobuf for example).

Would also make sense to then split the big Pipeline PR into separate PRs, one for memory pooling and another for the actual pipeline integration.

[lukebakken]

Would also make sense to then split the big Pipeline PR into separate PRs, one for memory pooling and another for the actual pipeline integration.

Smaller PRs are great... there's a chance I can understand them 😄