iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In Neil Colvin’s reported test on a Crestron MC4-R, System.Text.Json 10.0.12 parsed a small synthetic payload faster and allocated fewer managed bytes than Newtonsoft.Json 13.0.5-beta1. The result is relevant to developers targeting that processor, but it covers one warmed deserialization workload—not every driver, firmware, or JSON feature.
What the MC4-R test measured
Colvin ran the test on a Crestron MC4-R hardware version 2 with firmware 2.8000.00057, Crestron Home 4.011.0322, Mono 6.12.0.107, and CLR version 4.0.30319.42000. The serializer assemblies were merged into the test package as private copies. This is direct evidence from the stated processor setup, rather than a desktop or server benchmark. Colvin’s test and configuration.
The workload used one synthetic 409-byte response shaped like a WeatherLink API response. Both libraries deserialized it into the same nullable DTOs carrying attributes for both serializers. System.Text.Json used AllowReadingFromString; Newtonsoft.Json used its defaults.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →For each serializer, Colvin reports 200 warm-up parses, followed by four alternating rounds of 3,000 synchronous deserializations. He ran garbage collection before each round, measured time with Stopwatch, and measured allocations with GC.GetAllocatedBytesForCurrentThread. The harness ran remotely on the processor through his test adapter.
#1 Best Overall
Reported speed and allocation results
| Measure | System.Text.Json 10.0.12 | Newtonsoft.Json 13.0.5-beta1 | Reported difference |
|---|---|---|---|
| Time per parse | 0.108 ms | 0.147 ms | System.Text.Json was 26.5% faster |
| Allocated bytes per parse | 1,024 B | 3,816 B | System.Text.Json allocated 73.2% fewer bytes |
These are Colvin’s reported measurements for this payload and configuration, not independently replicated results. The lower allocation figure may be relevant when a processor is shared with other drivers, as Colvin notes; the timing difference for a small weather-polling parse is modest in absolute terms. Whether either difference matters in a particular installation depends on its polling frequency and total driver workload.
What the result does—and does not—tell you
The measured case was warmed deserialization of one small payload shape. It did not measure cold-start cost, serialization, peak memory, larger or differently shaped responses, or whole-driver CPU usage. Colvin describes the result as one firmware on one processor, not a platform-wide guarantee.
Use the figures as a reason to test System.Text.Json in a similar MC4-R workload, not as a substitute for that test. If your driver processes different payloads, depends on startup performance, serializes JSON, or runs alongside several busy drivers, those conditions may change the practical trade-off.
Version parity and package compatibility
The Newtonsoft.Json comparison used 13.0.5-beta1, a prerelease that Colvin says had been unlisted on NuGet. He identified 13.0.4 as the latest stable release and had not rerun the benchmark against it. The figures therefore are not a stable-versus-stable comparison.
Microsoft lists the System.Text.Json NuGet package as supporting .NET Framework 4.6.2 and later, so net472 is within the declared framework-target range. That does not by itself establish compatibility with every Mono version, Crestron firmware, or dependency graph; the MC4-R test is evidence only for the specific configuration above. See Microsoft’s migration guidance.
Colvin also reports that standard Newtonsoft.Json 13.0.2 and Newtonsoft.Json.Compact 4.0.8.0 were resident in /simpl/app00/ on his stated firmware, while System.Text.Json was not. He therefore shipped System.Text.Json inside the package and warns that dependencies should be merged to avoid DLL conflicts. Those are firmware-specific observations; the Compact assembly was not benchmarked.
Rank #4
Behavior differences to check before migrating
Performance is only useful if the replacement reads the JSON your driver actually receives. Microsoft says System.Text.Json is stricter by default and does not aim for full Newtonsoft.Json feature parity. Review real payloads, DTO attributes, converters, and any Newtonsoft-specific features the project relies on before switching.
| Behavior | Newtonsoft.Json default | System.Text.Json default | Migration implication |
|---|---|---|---|
| Property-name matching | Case-insensitive | Case-sensitive | Names that differ only by case may bind differently; review naming policies and payloads. |
| Comments and trailing commas | Ignored by default | Rejected by default | Enable supported options or normalize input if the incoming JSON uses these forms. |
| Single-quoted strings and quoted numbers | Accepted in more cases | Stricter defaults | Options or converters can address some cases; test the exact input rather than assuming equivalent behavior. |
Microsoft documents options and converters for some differences, but other gaps may require substantial code changes or have no practical workaround. Treat successful compilation as only one migration check: verify representative payloads and error handling on the target device.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
