Static ReadOnlySpan<byte> optimization reduces memory allocation

[pCYSl5EDgo]

private static readonly byte[] Hoge = new byte[] { /* some values */ };

can be optimized by being replaced with

private static ReadOnlySpan<byte> GetHoge() => new byte[] { /* some values */ };

[AArnott]

Wow. TIL 🎉. Thanks.

[AArnott]

I had to check sharplab to make sure we weren't allocating arrays on every invocation. Sure enough, you're right. :)

[neuecc]

@AArnott @pCYSl5EDgo
Is this efficient in Unity and IL2CPP?
Basically, I believe it will work with the Slow Span equivalent.
It seems to me that the savings in .NET Core are not balanced by the penalties in IL2CPP.

[AArnott]

Oooh. Good point, @neuecc. Shall we roll it back?

It's easy enough to see how the C# compiler interprets this and verify that it's a win. How can we tell what the Unity C# compiler does?
If IL2CPP takes IL and converts it to native, I would guess it doesn't make it worse. But if it takes the Unity C# compiler's IL as input, then we might still have a problem.

[pCYSl5EDgo]

I'll install Unity2018.4.27f1 and emit IL2CPP C++ codes.
Unity 2018.x uses csc v2.9.1.x.
I guess IL generated by Unity C# compiler is not different from the one of .NET Core.

Anyway, I'll examine it.

[neuecc]

IL is the same, but JIT's optimization for Span doesn't work.
In other words, new ReadOnlySpan..., indexer access to Span is slower than .NET Core.
It's probably not going to make much of a difference in performance.
However, I think should not do minor tricks if it's not a very beneficial in .NET Core.

I think we'll leave it as it is this time, but it's one of the factors we'll consider in the future.

[pCYSl5EDgo]

Okay, it is not the time.
We should roll it back.

I think the time is when the oldest Unity LTS supports .NET 5.0.