Benchmarks

This section compares the performance of Boost.JSON with two widely used libraries with similar functionality: RapidJSON which is known for its performance, and JSON for Modern C++ which is known for feature-richness. The bench program measures the throughput of parsing and serialization for the a set of JSON representing typical workloads. These implementations are evaluated:

Table 7. Implementations
Name	Description
boost(pool)	Parses the input using a `monotonic_resource`, which is optimized for parsing without subsequent modification. The `stream_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 the standard C++ allocator, and is designed for general use including mutation of the document after it is parsed. The `stream_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 without 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 the standard C++ allocator, and is designed for general use including mutation of the document after it is parsed. The `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 on subsequent operations.

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 throughput expressed in megabytes per second. Several samples (currently five) are generated for each configuration. All but the median two 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 8. Input Files
Name	Size	Description
apache_builds.json	125KB	Data from the Apache Jenkins installation.
canada.json	2.2MB	The largest file, containing a large 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.
github_events.json	64KB	An export of data from the Github Events API.
gsoc-2018.json	3.25MB	Google Summer of Code 2018 data.
instruments.json	216KB	An array of large objects.
marine_ik.json	2.91MB	A three.js example model serialized to JSON.
mesh.json	707KB	A JSON representing a 3D mesh. Contains many floating-point numbers.
mesh.pretty.json	1.54MB	mesh.json with whitespace added.
numbers.json	147KB	A array containing only floating-point numbers.
random.json	499KB	A JSON with lots of Cyrillic characters.
twitter.json	617KB	An export of data from Twitter’s API.
twitterescaped.json	550KB	twitter.json with whitespace removed and non-ASCII characters replaced with Unicode escapes.
update-center.json	521KB	An export of data from Twitter’s API.