System.Text.Json missing streaming reader in runtime / adopt existing implementation?

[bjornharrtell]

Hi,

I've since some time implemented streaming readers based on System.Text.Json that has been in production use for use cases with very large JSON payloads retrieved via stream. Source lives at https://github.com/bjornharrtell/Utf8JsonStreamReader and published at nuget at https://www.nuget.org/packages/Utf8JsonStreamReader and benchmarks has shown it's faster than corresponding NewtonsoftJson based logic UPDATE: recent experiments suggest sync variant of Newtonsoft streaming reader is actually faster.

I recall being surprised something similar wasn't already in the runtime. Actually I find it strangely asymmetric that the official Utf8JsonWriter is a class that can write to stream but Utf8JsonReader is a ref struct and can only work with in memory buffer.

I wonder if there are interest in officially adopting my implementation?

[huoyaoyuan]

Being async at every read/write operation is not performant.
Utf8JsonWriter is synchronous at every write. It writes to its internal buffer and flushes asynchronously when you call FlushAsync.
Utf8JsonReader is synchronous at every read. However there's not public utility that helps you reload buffer asynchronously when you reach the end.

Such utility should expose synchronous TryRead and asynchronously FillBufferAsync.

There's also space for improvement in your shape of implementation:

• ReadAsync should be ValueTask based. Since there's a high chance of completing synchronously, using ValueTask will provide significant benefit even when not pooling manually.
• Returning boxed value by default will increase boxing significantly.
• It's not clear to me how your implementation handles huge string tokens that is larger than your buffer size.

[bjornharrtell]

I've realised the my design/implementation was flawed and buffering up results isn't effective, at least not in terms of memory footprint. I've reworked into delegate interface now which seems to be both faster and small memory footprint.

[bjornharrtell]

Latest benchmark:

BenchmarkDotNet v0.13.12, Ubuntu 23.10 (Mantic Minotaur)
Intel Core i7-1065G7 CPU 1.30GHz, 1 CPU, 8 logical and 4 physical cores
.NET SDK 8.0.103
  [Host]     : .NET 8.0.3 (8.0.324.11423), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
  DefaultJob : .NET 8.0.3 (8.0.324.11423), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI


| Method                               | Objects | Mean      | Error    | StdDev   |
|------------------------------------- |-------- |----------:|---------:|---------:|
| TraverseUtf8JsonStreamReader         | 100000  |  62.55 ms | 0.676 ms | 0.632 ms |
| TraverseUtf8JsonStreamReaderRawValue | 100000  |  28.15 ms | 0.139 ms | 0.124 ms |
| TraverseNewtonsoftJsonTextReader     | 100000  | 108.26 ms | 0.840 ms | 0.786 ms |

[huoyaoyuan]

@eiriktsarpalis With STJ getting Pipelines support, is there anything applicable to this?

[davidfowl]

This might help https://devblogs.microsoft.com/dotnet/the-convenience-of-system-text-json/

[eiriktsarpalis]

With STJ getting Pipelines support, is there anything applicable to this?

The pipelines APIs will be added to JsonSerializer, which lives higher in the stack. Presumably this question concerns the low-level reader type.