Parsing gigabytes of JSON per second

Abstract

JavaScript Object Notation or JSON is a ubiquitous data exchange format on the web. Ingesting JSON documents can become a performance bottleneck due to the sheer volume of data. We are thus motivated to make JSON parsing as fast as possible. Despite the maturity of the problem of JSON parsing, we show that substantial speedups are possible. We present the first standard-compliant JSON parser to process gigabytes of data per second on a single core, using commodity processors. We can use a quarter or fewer instructions than a state-of-the-art reference parser like RapidJSON. Unlike other validating parsers, our software (simdjson) makes extensive use of single instruction and multiple data instructions. To ensure reproducibility, simdjson is freely available as open-source software under a liberal license.

Appendices

Effect of minification

Table 11 Millions of cycles required to parse and validate selected documents (Skylake), before and after minification

To ease readability, JSON documents may contain a variable number of white space characters between atoms, within objects and arrays. Intuitively, these superfluous characters should reduce parsing speed. To verify this intuition, we minified the documents prior to parsing. We find that all three parsers (simdjson, RapidJSON, sajson) use fewer CPU cycles to parse minified documents, see Table 11. However, the benefits in processing speed are often less than the benefits in storage. For example, the minified apache_builds file is 74% of the original, yet the processing time is only reduced to between 82% and 90% of the original—depending on the parser. The sajson parser often benefits more from minification. Thus while simdjson is more than 2.1 times faster than sajson on the original twitter document, it is only 1.9 times faster after minification.

Effect of specific optimizations

In a complex task like JSON parsing, no single optimization is likely to make a large difference. Nonetheless, it may be useful to quantify the effect of some optimizations.

• We can compute the string masks (indicating the span of the strings) using a single carry-less multiplication between a word containing the location of the quote characters (as 1-bits) and a word containing only ones (see Sect. 3.1.1). Alternatively, we can achieve the same result with a series of shifts and XOR:

  

• Instead of extracting the set bits using our optimized algorithm (see Fig. 6 in Sect. 3.1.4), we can use a naive approach:

  

• Instead of using vectorized classification (Sect. 3.1.2), we can use a more naive approach where we detect the locations of structural characters by doing one vectorized comparison per structural character and doing a bitwise OR. Similarly, we can detect spaces by doing one comparison per allowable white space character and doing a bitwise OR.

We present the number of cycles per input byte in Table 12 with the three optimizations disabled one by one. The standard error of our measure is about 0.02 cycles per byte so small differences ($<0.05$ cycles) may not be statistically significant. The fast index extraction reduces the cost of the stage 1 by over 10% in several instances (e.g., twitter, update-center). The carry-less multiplication appear has gains of over 5% in some instance; the gains reach nearly 20% in one instance (mesh). Vectorized classification is similarly helpful.

Table 12 Performance in cycles per bytes of the simdjson parser during stage 1 over several files

Large files

All three fast parsers (simdjson, RapidJSON, and sajson) mostly read and write sequentially in memory. Furthermore, the memory bandwidth of our systems are far higher than our parsing speeds. Thus we can expect them to perform well even when all of the data does not fit in cache. To verify that we can still process JSON data at high speed when the input data exceeds the cache, we created a large file (refsnp-unsupported35000) made of the first 35,000 entries from a file describing human single nucleotide variations (refsnp-unsupported.json). Table 13 shows that we far exceed 1 GB per second with simdjson in this instance although the file does not fit in CPU cache.

Table 13 Throughput in GB/s when parsing a large (84 MB) file: refsnp-unsupported35000