This is great. How did you detect it?

In the best-case scenario when an entire dictionary fits in a buffer - it should completely remove unnecessary heap allocations for keys.

Can we run some benchmarks to get a sense of how much heap allocations we save? It might help modifying and running this benchmark on a dictionary input that you expect to get performance wins on (with value type keys). Please share the benchmarkdotnet results when you have them:
https://github.com/dotnet/performance/blob/0b094042e7dc114c8cd038b1ae90dad0e5696fa2/src/benchmarks/micro/libraries/System.Text.Json/Serializer/ReadJson.cs#L57-L64

This is great. How did you detect it?

In the best-case scenario when an entire dictionary fits in a buffer - it should completely remove unnecessary heap allocations for keys.

Can we run some benchmarks to get a sense of how much heap allocations we save? It might help modifying and running this benchmark on a dictionary input that you expect to get performance wins on (with value type keys). Please share the benchmarkdotnet results when you have them:
https://github.com/dotnet/performance/blob/0b094042e7dc114c8cd038b1ae90dad0e5696fa2/src/benchmarks/micro/libraries/System.Text.Json/Serializer/ReadJson.cs#L57-L64

I am currently working on the high-performance dynamodb library which involves some low-level optimized JSON deserialization. I was able to detect several inefficiencies during some internal benchmark comparisons.

Here is the benchmark result forDictionary<int, string> with100 items. I think the most important column for this case isAllocated, where we can see that the2KB difference disappears after the PR. It also becomes slightly faster.

BenchmarkDotNet=v0.12.1.1466-nightly,OS=Windows 10.0.19041.572 (2004/May2020Update/20H1)Intel Core i7-7820X CPU 3.60GHz (Kaby Lake), 1 CPU, 6 logical and 3 physical cores.NETSDK=6.0.100-alpha.1.20630.6  [Host]     : .NET 6.0.0 (6.0.20.62903), X64 RyuJIT  Job-NDNXAQ : .NET 6.0.0 (42.42.42.42424), X64 RyuJIT  Job-EVXCXL : .NET 6.0.0 (42.42.42.42424), X64 RyuJITPowerPlanMode=00000000-0000-0000-0000-000000000000Arguments=/p:DebugType=portableIterationTime=250.0000 msMaxIterationCount=20MinIterationCount=15WarmupCount=1

It is also worth noting another potential optimization that I am considering to create a PR for. On the benchmark, you can see that deserialization fromStream is visibly slower than from bytes array even when entire JSON fits in a single buffer. I suspect it happens because we don't useUseFastPath for a single buffer case. But it is unrelated and probably not worth discussing in this thread.

Looks like we have a couple approvals: Is this ready to merge? Might want to get fresh test results (current are from Jan 5)