Benchmarks

In this section we compare the performance of Boost.JSON against the other two important libraries of interest, RapidJSON which is known for its considerable performance and nlohmann which underperforms but is feature-rich. The bench program measures the throughput of serialization and parsing for the various JSON files located in the data directory. It tests these implementations:

Table 10. Implementations

Name	Description
boost(pool)	Parses the input using a `monotonic_resource`, which is optimized for parsing but not subsequent modification. The `parser` object is reused between trials, allowing temporary memory allocated by the implementation to persist and improve performance.
boost	Parses the input using the default memory resource, which uses global operator `new` and `delete`, and is designed for general use including mutation of the document after it is parsed. The `parser` object is reused between trials, allowing temporary memory allocated by the implementation to persist and improve performance.
rapidjson(pool)	Parses the input using an instance of `MemoryPoolAllocator`, which is optimized for parsing but not subsequent modification. The `Document` object holding temporary memory is not reused between trials, otherwise memory consumption grows without bounds and invalidates the benchmark.
rapidjson	Parses the input using an instance of `CrtAllocator`, which uses global operators `new` and `delete`, and is designed for general use including mutation of the document after it is parsed. `Document` object holding temporary memory is not reused between trials, otherwise memory consumption grows without bounds and invalidates the benchmark.
nlohmann	Parses the input using the static member function `json::parse`, which uses the default `std` allocator, and is designed for general use including mutation of the document after it is parsed. This library does not provide an interface to reuse temporary storage used during parsing or serialization.

Methodology

The input files are all loaded first. Then each configuration is run for a sufficient number of trials to last at least 5 seconds. The elapsed time, number of invocations (of parse or serialize), and bytes transferred are emitted as a sample along with a calculation of through put expressed in megabytes per second. Several samples (currently six) are generated for each configuration. All but the median three samples are discarded, with the remaining samples averaged to produce a single number which is reported as the benchmark result.

The input files, available in the bench/data directory, are laid out thusly:

Table 11. Input Files

Name	Size	Description
array.json	667KB	A single array with random values and words.
canada.json	2.14MB	The largest file, containing a huge number of 2-element arrays holding floating-point coordinate pairs.
citm_catalog.json	1.69MB	A large JSON with a variety of nesting, types, and lengths.
integers-32.json	1,353KB	One array with random 32-bit integers.
integers-64.json	596KB	One array with random 64-bit integers.
random.json	2,244 bytes	Holds a randomly generated JSON with assorted types.
small.json	603 bytes	Containing a few nested objects with strings.
strings.json	992KB	Contains a single array with random long strings.
twitter.json	631KB	An export of data from Twitter's API.

Hardware used for testing: Intel(R) Core(TM) i7-6950X CPU @ 3.00GHz, Windows 10, 64GB RAM.

Thanks to SSE2 optimized string processing algorithms from Peter Dimov, Boost.JSON significantly outperforms all other libraries for parsing and serializing unescaped strings:

Benchmarks

Methodology

Parse strings.json

Serialize strings.json

Parse integers-32.json

Serialize integers-32.json

Parse integers-64.json

Serialize integers-64.json

Parse small.json

Serialize small.json

Parse array.json

Serialize array.json

Parse random.json

Serialize random.json

Parse twitter.json

Serialize twitter.json

Parse citm_catalog.json

Serialize citm_catalog.json

Parse canada.json

Serialize canada.json