Run ./run.ps1 or ./run.sh at the repository root to repeat the experiment

What is the most performant method of data serialization for resources served by ASP.NET Core 2.1 APIs?

Three categories of serialization are tested:

• JSON
• CSV (with a single StringBuilder implementation)
• byte[]

Within the JSON category, these methodologies are tested:

• StringBuilder used to append values to string returned by .ToString() override
• The Jil JSON serialization library, version 2.15.4 with optional excludeNulls behavior
• The Newtonsoft.Json JSON serialization library, version 11.0.2

Newtonsoft.Json, Jil, CSV, and byte[] scenarios are also tested on an in-memory ASP.NET Core web host

Within the byte[] category, these methodologies are tested:

• Buffer.BlockCopy
• Span<byte>
• ReadOnlyMemory<byte> using CDorst.Common.Extensions.Memory
• ReadOnlySpan<byte> using CDorst.Common.Extensions.Memory
• protobuf-net protocol buffers
• MessagePack

Jil is expected to be more performant than Newtonsoft.Json based on the github.com/aspnet/benchmarks work

StringBuilder is expected to perform well given the benchmarking published in this blog post.

CSV should perform much better than JSON since it is schema-less.

Byte-array block copy should perform even better than CSV since it is also schema-less and contains less data.

The low-level ReadOnly Memory/Span types are expected to be more performant than the Buffer.BlockCopy implementation due to the simplicity of the serialization operation.

MessagePack is expected to outperform protobuf-net given these data. The simple Buffer.BlockCopy and ReadOnlyMemory/ReadOnlySpan are expected to outperform the more fully-featured MessagePack serializer.

BenchmarkDotNet=v0.10.14, OS=Windows 10.0.17134
Intel Core i7-7700HQ CPU 2.80GHz (Kaby Lake), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=2.1.300-rc1-008673
  [Host]     : .NET Core 2.1.0-rc1 (CoreCLR 4.6.26426.02, CoreFX 4.6.26426.04), 64bit RyuJIT
  Job-BHDFIP : .NET Core 2.1.0-rc1 (CoreCLR 4.6.26426.02, CoreFX 4.6.26426.04), 64bit RyuJIT

LaunchCount=10  

CSV byte[] length: 15

JSON byte[] length: 72

Bytes byte[] length: 8

MessagePack byte[] length: 11

Protobuf byte[] length: 8

CSV string is 4.8x more compact than JSON representation

ToBytes result is 9.0x more compact than JSON representation and 1.9x more compact than CSV

In-memory ASP.NET Core web server Jil JSON endpoint responds 13.11% faster than default JsonFormatter endpoint

In-memory ASP.NET Core web server CSV endpoint responds 23.43% faster than default JsonFormatter endpoint

In-memory ASP.NET Core web server byte[] endpoint responds 27.21% faster than default JsonFormatter endpoint

Entity serialized and deserialized to and from bytes printed as json: {"EntityId":1000000,"ForeignKeyOneId":1000001,"ForeignKeyTwoId":1000002}

byte[] (especially ReadOnlyMemory/Span) serialization outperforms other methods in terms of data-size, serialization runtime, and API request-response runtime.

The resultant Data Table indicates that the in-memory ASP.NET Core server is less performant in handling object results (with or without a Formatter attribute) than when handling IActionResults

Compare the Jil with JilFormatterAttribute, Jil with JsonActionResult, CSV, and byte[] endpoint performance using a non in-memory test infrastructure like the github.com/aspnet/benchmarks project.

Demonstration of better performance with Jil IActionResult scenario than JilFormatterAttribute scenario could yield an improved aspnetcore-mvc-linux Json Serialization TechempowerBenchmarks score