A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/go-json-experiment/jsonbench below:

go-json-experiment/jsonbench: JSON benchmarks to compare different Go JSON implementations

Each of the charts below show the performance across several different JSON implementations:

The JSONv1in2 implementation replicates the JSONv1 API and behavior purely in terms of the JSONv2 implementation by setting the appropriate set of options to reproduce legacy v1 behavior.

The Go toolchain used is v1.23.5.

Based on the module proxy as of 2025-01-22, the relative popularity of each:

Note that JSONv2 deliberately dissuades users from depending on the package as it is an experiment and is subject to major breaking changes.

Benchmarks were run across various datasets:

All of the implementations other than JSONv1, JSONv1in2, JSONv2, and Sonnet make extensive use of unsafe. As such, we expect those to generally be faster, but at the cost of memory and type safety. SonicJSON goes a step even further and uses just-in-time compilation to generate machine code specialized for the Go type being marshaled or unmarshaled. Also, SonicJSON does not validate JSON strings for valid UTF-8, and so gains a notable performance boost on datasets with multi-byte Unicode. Benchmarks are performed based on the default marshal and unmarshal behavior of each package. Note that JSONv2 aims to be safe and correct by default, which may not be the most performant strategy.

JSONv2 has several semantic changes relative to JSONv1 that impacts performance:

  1. When marshaling, JSONv2 no longer sorts the keys of a Go map. This will improve performance.

  2. When marshaling or unmarshaling, JSONv2 always checks to make sure JSON object names are unique. This will hurt performance, but is more correct.

  3. When marshaling or unmarshaling, JSONv2 always shallow copies the underlying value for a Go interface and shallow copies the key and value for entries in a Go map. This is done to keep the value as addressable so that JSONv2 can call methods and functions that operate on a pointer receiver. This will hurt performance, but is more correct.

  4. When marshaling or unmarshaling, JSONv2 supports calling type-defined methods or caller-defined functions with the current jsontext.Encoder or jsontext.Decoder. The Encoder or Decoder must contain a state machine to validate calls according to the JSON grammar. Maintaining this state will hurt performance. The JSONv1 API provides no means for obtaining the Encoder or Decoder so it never needed to explicitly maintain a state machine. Conformance to the JSON grammar is implicitly accomplished by matching against the structure of the call stack.

All of the charts are unit-less since the values are normalized relative to JSONv1, which is why JSONv1 always has a value of 1. A lower value is better (i.e., runs faster).

Benchmarks were performed on an AMD Ryzen 9 9950X.

When reading from an io.Reader and writing to an io.Writer, a JSON implementation should not need a buffer much larger than the largest JSON token encountered within the entire JSON value. For example, marshaling and unmarshaling a [{},{},{},{},{},...] that is a gigabyte in size should not need to buffer the entire JSON array, but only enough to buffer each individual { or }. An implementation with true streaming support will use a fixed amount of memory regardless of the total size of the JSON value.

The following implementations have true streaming support:

Implementation Marshal Unmarshal JSONv1 ❌ ❌ JSONv1in2 ❌ ❌ JSONv2 ✔️ ✔️ JSONIterator ❌ ✔️ SegmentJSON ❌ ❌ GoJSON ❌ ❌ SonicJSON ❌ ❌ SonnetJSON ❌ ❌

See TestStreaming for more information.

A package may be fast, but it must still be correct and realiable.

While it is possible to use unsafe correctly, it is difficult to do so as you lose the benefits of type safety. Even experienced Go programmers have introduced bugs with unsafe that could lead to memory corruption, remote code execution, or worse.

The following table shows whether each implementation uses unsafe:

Implementation Uses unsafe JSONv1 🛡️ no JSONv1in2 🛡️ no JSONv2 🛡️ no JSONIterator 💣 yes SegmentJSON 💣 yes GoJSON 💣 yes SonicJSON 💣 yes SonnetJSON 🛡️ no

Notes:

Our test suite was unable to trigger any memory corruption bugs in JSONIterator, SegmentJSON, or SonicJSON, which do use unsafe. Similarly, our test quite was unable to trigger any memory corruption bugs in JSONv1, JSONv1in2, JSONv2, and SonnetJSON, which do not use unsafe, but could still have race conditions. The inability to trigger bugs does not imply that there are no bugs. Caveat emptor.

According to RFC 8259, section 8.1, a JSON value must be encoded using UTF-8.

The following table shows how each implementation handles invalid UTF-8:

Implementation Marshal Unmarshal JSONv1 ⚠️ replaced ⚠️ replaced JSONv1in2 ⚠️ replaced ⚠️ replaced JSONv2 ✔️ rejected ✔️ rejected JSONIterator ⚠️ replaced ❌ ignored SegmentJSON ⚠️ replaced ⚠️ replaced GoJSON ⚠️ replaced ❌ ignored SonicJSON ❌ ignored ❌ ignored SonnetJSON ⚠️ replaced ⚠️ replaced

Notes:

See TestValidateUTF8 for more information.

RFC 8259, section 4 specifies that handling of a JSON object with duplicate names results in undefined behavior where compliant parsers may use the first member, the last member, all the members, or report an error. RFC 7493, section 2.3 specifies that JSON objects must not have duplicate names. Rejecting duplicate object names is more correct, but incurs a performance cost verifying this property.

The following table shows how each implementation handles duplicate object names:

Implementation Marshal Unmarshal JSONv1 ❌ allowed ❌ allowed JSONv1in2 ❌ allowed ❌ allowed JSONv2 ✔️ rejected ✔️ rejected JSONIterator ❌ allowed ❌ allowed SegmentJSON ❌ allowed ❌ allowed GoJSON ❌ allowed ❌ allowed SonicJSON ❌ allowed ❌ allowed SonnetJSON ❌ allowed ❌ allowed

See TestDuplicateNames for more information.

"Parsing JSON is a Minefield 💣" (posted 2016-10-26) performed one of the first thorough comparisons of JSON parsers and their behavior on various edge-cases. At the time, RFC 7159 was the authoritative standard, but has since been superseded by RFC 8259. Consequently, the expected results of some of the test cases from the article were changed to be more compliant with RFC 8259.

The following table shows the number of test case failures for each implementation when tested against RFC 8259:

Implementation String Number Object Array Other JSONv1 ❌ 10x ✔️ ✔️ ✔️ ✔️ JSONv1in2 ❌ 10x ✔️ ✔️ ✔️ ✔️ JSONv2 ✔️ ✔️ ✔️ ✔️ ✔️ JSONIterator ❌ 10x ❌ 4x ✔️ ✔️ ✔️ SegmentJSON ❌ 10x ✔️ ✔️ ✔️ ✔️ GoJSON ❌ 30x ❌ 52x ❌ 20x ❌ 17x ❌ 10x SonicJSON ❌ 28x ✔️ ✔️ ❌ 1x ✔️ SonnetJSON ❌ 10x ✔️ ✔️ ✔️ ✔️

RFC 7493 is compatible with RFC 8259 in that it makes strict decisions about behavior that RFC 8259 leaves undefined. In particular, it rejects escaped surrogate pairs that are invalid and rejects JSON object with duplicate names.

The following table shows additional test case failures for each implementation when tested against RFC 7493:

Implementation String Number Object Array Other JSONv1 ❌ 9x ✔️ ❌ 3x ✔️ ✔️ JSONv1in2 ❌ 9x ✔️ ❌ 3x ✔️ ✔️ JSONv2 ✔️ ✔️ ✔️ ✔️ ✔️ JSONIterator ❌ 9x ✔️ ❌ 3x ✔️ ✔️ SegmentJSON ❌ 9x ✔️ ❌ 3x ✔️ ✔️ GoJSON ❌ 9x ✔️ ❌ 3x ✔️ ✔️ SonicJSON ❌ 9x ✔️ ❌ 3x ✔️ ✔️ SonnetJSON ❌ 9x ✔️ ❌ 3x ✔️ ✔️

See TestParseSuite for more information.

A JSON implementation should not trust that the output of a MarshalJSON method is valid JSON nor formatted in the same way as surrounding JSON. Consequently, it should parse and reformat the JSON output to be consistent.

The following table shows which implementations validate MarshalJSON output:

Implementation Validates JSONv1 ✔️ yes JSONv1in2 ✔️ yes JSONv2 ✔️ yes JSONIterator ❌ no SegmentJSON ✔️ yes GoJSON ✔️ yes SonicJSON ✔️ yes SonnetJSON ✔️ yes

See TestValidateMarshalJSON for more information.

Deterministic Map Ordering

RFC 8259 specifies that JSON objects are an "unordered collection". Thus, a compliant JSON marshaler need not serialize Go maps entries in any particular order.

The JSONv1 implementation historically sorted keys, which consequently set the precedence for other JSON implementations to do likewise. The JSONv2 implementation no longer sorts keys for better performance and because it does not violate any specified facet of correctness.

The following table shows which implementations deterministically marshal maps:

Implementation Deterministic JSONv1 ✔️ yes JSONv1in2 ✔️ yes JSONv2 ❌ no JSONIterator ❌ no SegmentJSON ✔️ yes GoJSON ✔️ yes SonicJSON ❌ no SonnetJSON ❌ no

See TestMapDeterminism for more information.

Observable Changes With Unmarshal Errors

Implementations differ regarding how much of the output value is modified when an unmarshaling error is encountered.

There are generally two reasonable behaviors:

  1. Make no mutating changes to the output if the input is invalid.
  2. Make as many changes as possible up until the input becomes invalid.

The following table shows what changes are observable if the input is invalid:

Implementation Observable Changes JSONv1 ✔️ none JSONv1in2 ✔️ none JSONv2 ⚠️ all JSONIterator ⚠️ all SegmentJSON ❌ some GoJSON ❌ some SonicJSON ⚠️ all SonnetJSON ❌ some

See TestUnmarshalErrors for more information.

For use in embedded or mobile applications, a small binary size is a priority. The following table shows the binary sizes of each JSON implementation for a simple Go program that just links in json.Marshal and json.Unmarshal. These were built with GOOS=linux and GOARCH=amd64.

Implementation Size JSONv1 2.511 MiB JSONv1in2 3.460 MiB JSONv2 3.394 MiB JSONIterator 3.354 MiB SegmentJSON 3.035 MiB GoJSON 3.720 MiB SonicJSON 7.100 MiB SonnetJSON 2.479 MiB

See TestBinarySize for more information.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4