The perf is significantly slower after this change. I haven't studied the ETL trace, but my guess is we won't find an efficient way to call from the reader/writer structs into the MessagePackPrimitives class. If we bring back this class from v1, it may be without any use case within the library for it, which means we'll have to add tests specifically for it.

@neuecc Do you have any time and interest in mitigating the perf regressions here? Should we abandon the PR?

The MessagePackWriter shouldn't be fundamentally any slower after this change. The fact that it is slower suggests something we can probably fix (e.g. bring back AggressiveInline attributes that I may have dropped).

It's the MessagePackReader side that I'm more concerned about inescapable perf hits. But I'm not sure.

Thanks, I'll check now.

I added ReadBytePrimitiveInt32 and got this result:

[Benchmark(OperationsPerInvoke = BufferLength)]
[BenchmarkCategory("2.0")]
public void ReadBytePrimitiveInt32()
{
    int offset = 0;
    for (int i = 0; i < this.buffer.Length; i++)
    {
        newmsgpack::MessagePack.MessagePackPrimitives.TryReadInt32(this.buffer.AsSpan(offset), out int value, out var readSize);
        offset += readSize;
    }
}

I think the overhead simply doubled.
After trying a few things, it seemed that the size of the method itself was having an impact.
Just by moving the FixedInt code to the true branch of an if statement and placing/not placing a switch statement on the else side, the benchmark results changed significantly.

The contents of v1 pushed the branching into array and virtual method calls, making the method body very small.

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static int ReadInt32(byte[] bytes, int offset, out int readSize)
{
    return int32Decoders[bytes[offset]].Read(bytes, offset, out readSize);
}

I tried various approaches, but it seems difficult to achieve performance equivalent to this...

Note that for the benchmark measurements, I was using WarmupCount 1 and IterationCount 1 to speed up the execution iterations.

class BenchmarkConfig : ManualConfig
{
    public BenchmarkConfig()
    {
        AddJob(Job.ShortRun.WithWarmupCount(1).WithIterationCount(1));
    }
}

[Config(typeof(BenchmarkConfig))]
[GroupBenchmarksBy(BenchmarkLogicalGroupRule.ByCategory)]
[CategoriesColumn]
public class MessagePackReaderBenchmark

By the way, the excessive overloading specification was difficult to use.
I don't think it's a good design to separate methods based on the type of the out parameter.
It should be done like TryReadInt32 so that it can be received with var.
This would also maintain symmetry with MessagePackReader.

@neuecc Excellent perf hints. Thank you. I have a prototype with these numbers:

That's better than v2's original perf before my change. Yay.

I've updated the benchmark tables in the PR description. Read speed is awesome. Write speed is regressed. Based on what I've learned in speeding up read speeds, I think I know why.