Remove unnecessary endianness dependent logic

[buyaa-n]

Before my PR #102364 the Base64Encoder was populating uint by concatenating encoded 4 bytes (by accounting the endianness)

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 533 to 545 in 4a37e73

	uint i0 = Unsafe.Add(ref encodingMap, (IntPtr)(i >> 18));
	uint i1 = Unsafe.Add(ref encodingMap, (IntPtr)((i >> 12) & 0x3F));
	uint i2 = Unsafe.Add(ref encodingMap, (IntPtr)((i >> 6) & 0x3F));
	uint i3 = Unsafe.Add(ref encodingMap, (IntPtr)(i & 0x3F));
	if (BitConverter.IsLittleEndian)
	{
	return i0 | (i1 << 8) | (i2 << 16) | (i3 << 24);
	}
	else
	{
	return (i0 << 24) | (i1 << 16) | (i2 << 8) | i3;
	}

and was writing that uint to the destination buffer:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 95 to 96 in 4a37e73

	result = Encode(src, ref encodingMap);
	Unsafe.WriteUnaligned(dest, result);

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once), where I kept the endianness logic when I should not, endianness has no effect for ASCII characters:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Helper/Base64EncoderHelper.cs

Lines 766 to 784 in 745b776

	byte i0 = Unsafe.Add(ref encodingMap, (IntPtr)(i >> 18));
	byte i1 = Unsafe.Add(ref encodingMap, (IntPtr)((i >> 12) & 0x3F));
	byte i2 = Unsafe.Add(ref encodingMap, (IntPtr)((i >> 6) & 0x3F));
	byte i3 = Unsafe.Add(ref encodingMap, (IntPtr)(i & 0x3F));
	if (BitConverter.IsLittleEndian)
	{
	destination[0] = i0;
	destination[1] = i1;
	destination[2] = i2;
	destination[3] = i3;
	}
	else
	{
	destination[3] = i0;
	destination[2] = i1;
	destination[1] = i2;
	destination[0] = i3;
	}

Fixes #104283

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[stephentoub]

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once)

Why?

[buyaa-n]

Why?

I think I had build error for Unsafe.WriteUnaligned(dest, result); when changed the dest type to T, though that doesn't seem happen now, is this less performant? I can revert that change NO, I need to keep it

[buyaa-n]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[stephentoub]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

But writing to a ulong would work in that case, no?

[buyaa-n]

But writing to a ulong would work in that case, no?

Did not think about that 😄. Though it looks to me more efficient, no? Compared to doing several |, << operations, I can change then

[buyaa-n]

Though it looks to me more efficient, no?

According to the local perf test, turns out the old approach is bit more performant, reverted to old approach except the case where padding is omitted and not writing 4 bytes to destination

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).