Use non-allocating Int64 key generation

[benaadams]

Contributes to #7392

Changes

• Create span over the Int64 rather than allocating byte[]

Types of changes

What types of changes does your code introduce?

• Optimization

Testing

Requires testing

• No

[LukaszRozmej]

WHy does it mutate the original value? Is that safe?

[benaadams]

Its needs to return the Span over valid stackspace so it takes the long by ref and creates the span over it; so its valid

The wrinkle is it also needs to change its byte order from little endian to big endian; trashing the local variable on the other side.

However there are only two instances where that's important; one I moved this call down one so is last use; and other I take a copy to a new local so the rest of the method can keep using the original value

[LukaszRozmej]

wouldn't it be better to always stackalloc 8 bytes?

[benaadams]

Can't return the stackalloc'd to the caller as it will have been unwound so no longer valid. Caller needs to allocate the space

[benaadams]

I could through in an out var and then mutate that instead so

ReadOnlySpan<byte> ToBigEndianSpanWithoutLeadingZeros(this long value, out long bigEndian)

Then in use it would be:

key.ToBigEndianSpanWithoutLeadingZeros(out _)

but that's pretty horrible too

[LukaszRozmej]

I like this one a lot better - not to cut yourself. Looks good enough to me. Do it on <T> for all the numbers! :)

[benaadams]

Isn't a T constraint for ReverseEndianness; which does seem a missed opportunity for the runtime