rjson

rjson is a json parser that relies on Ragel-generated state machines for most parsing. rjson's api is minimal and focussed on efficient parsing.

Ragel state machines

This whole thing is built around a few Ragel-generated state machines. They are defined in .rl files, and the generated code is in .rl.go files. If you peek at the generated code, beware that it doesn't look like anything intended to be read by a human.

Read functions

rjson provides Read functions for simple json values (strings, numbers, booleans and null). They each take a data []byte argument and read the first json value in data. They return a p int value that is the offset of the first byte after the value they read. When used in a handler, this p should be returned as the handler's p.

Read functions return an error for any json type other than the type they are meant to read. This includes null. So if there is a value that could be either a string or null, be sure to use NextTokenType to check which one it is.

ReadString and ReadStringBytes take a buf []byte argument. ReadStringBytes returns the result appended to buf and ReadString uses it as a byte buffer when decoding strings to avoid memory allocations. buf may be nil in both cases.

Handlers

rjson uses handlers to parse complex json values (objects and arrays). The handler will implement either HandleArrayValue(data []byte) (p int, err error) or HandleObjectValue(fieldname, data []byte) (p int, err error). data is the document being parsed from the current position to the end of the document.

The handler has to return p as either 0, or the offset after the last byte of the value it handled. This is important as it is how rjson knows where to resume parsing the document. When the handler returns 0, rjson uses SkipValue to find the next offset, so it is best to write handlers that return the next offset and avoid an extra call to SkipValue.

When your handler returns an error, HandleArrayValues and HandleObjectValues will immediately return the same error. You can use this to stop parsing a document once you have found all values you are after.

See HandleObjectValues's example

Standard Library Compatibility

rjson endeavors to decode json to the same values as the encoding/json functions. In the source code, most of rjson's exported functions are followed by an unexported version that produces the same output using encoding/json instead of rjson. These are used to ensure compatibility.

The RuneError compatibility exception

When decoding strings, encoding/json will replace bytes with values over 127 that aren't part of a valid utf8 rune with utf8.RuneError. I don't think this is correct behavior, and I have not found any other go json parser that does this, so rjson keeps those bytes as-is when decoding strings.

If you need those RuneErrors, you can use StdLibCompatibleString, StdLibCompatibleSlice, and StdLibCompatibleMap.

Differential Fuzz Testing

rjson uses fuzz testing extensively to test compatibility with encoding/json. See fuzzers.go for the fuzz functions and testdata/fuzz/corpus for the increasingly unwieldy corpus.

What rjson doesn't do

• drop in replacement for "encoding/json" - rjson doesn't aim to be a replacement for "encoding/json". It probably won't ever unmarshal json to a struct, and it definitely won't ever marshal json. It does one thing well, and that one thing is parsing json fast and with minimal memory allocations.

• import "unsafe" - Not that there is necessarily anything wrong with using unsafe where it is called for. It's just that you are better off avoiding it where possible, and it is possible here.

• return unchecked strings - Some json parsers use techniques like strings.IndexByte(data, '"') to skip to the end of a string and return the contents uninspected. This can be dangerous when dealing with json from untrusted sources. Those strings can contain control characters and other invalid json.

• parse from an io.Reader - I would like to implement this in the future, but it's off the table for now.

• keep a global resource pool - Some json packages have handy Borrow and Return functions that let you borrow resources and avoid new allocations. rjson leaves it up to the user to decide how to do resource pooling.

Performance principles and tricks

Handle each byte once

This is the main guiding principle of rjson performance. Do everything you can to avoid handling the same byte twice.

fp.ParseJSONFloatPrefix

fp.ParseJSONFloatPrefix is a rewrite of strconv.ParseFloat that deals in bytes instead of strings and eliminates everything not needed for parsing json numbers. This reduces the time to read numbers by about 60%. It's an internal package for now, but I encourage anybody who is parsing json numbers to consider copying this code or writing something similar.

Predict object and array size based on previous values

ReadObject and ReadArray can create a lot of nested maps and slices. It would be nice if we knew how big they would be ahead of time so we can make([]interface{}, 0, size), but we can't know that until we reach the end. In place of that, rjson keeps track of how big the values end up being and allocates values that are as big as the previous sibling value of the same type.

Always Be Benchmarking

Running benchmarks for every change keeps me from going too far down bad paths. Also, consistently benchmarking against other parsers shows me where rjson can be improved.

While I'm coding I frequently run benchdiff with script/benchdiff --benchtime 10ms --bench WhateverBenchmark to get a quick comparison with the previous commit. It takes just a couple of seconds to run, and it saves a lot of time down the road.

Benchmarks

Benchmarks are in ./benchmarks and run with script/compbench. Each package that is benchmarked has its own file that implements the various benchmarks.

JSON data

With the exception of github_repo.json, this is all taken from nativejson-benchmark

All tested JSON data are in UTF-8.

Compared packages

The go community is fortunate to have multiple high-performance options for parsing JSON. The benchmarks include some better known packages. They don't all have the same features, so not all the compared packages are represented in every benchmark. There are also some packages with incorrect Valid() functions. Those are excluded until they are fixed.

Every package should be able to put their best foot forward in the benchmarks. I have tried to write the best code for each package in the benchmark. If anybody sees a way to improve the benchmarks for any package, please create an issue to let me know.

This import statement has all the players seen in the benchmarks below:

import (
encoding_json "encoding/json"

jsonparser "github.com/buger/jsonparser"
jsoniter "github.com/json-iterator/go"
gjson "github.com/tidwall/gjson"
fastjson "github.com/valyala/fastjson"
rjson "github.com/willabides/rjson"
goccyjson "github.com/goccy/go-json"
)

Benchmarks

GetRepoValues

GetRepoValues gets three values of different types from github_repo.json and writes them to a struct. The same as running json.Unmarshal with this struct:

type repoData struct {
Archived bool   `json:"archived"`
Forks    int64  `json:"forks"`
FullName string `json:"full_name"`
}

Valid

Valid runs checks whether json data is valid. It's the equivalent of json.Valid(data)

ReadObject

ReadObject decodes json data to a map[string]interface{}.

ReadFloat64

ReadFloat64 parses a json number and returns its value as a float64.

ReadInt64

ReadInt64 parses a json number and returns its value as an int64.

ReadString

ReadString decodes a json string and returns its value as a string.

ReadBool

ReadBool decodes a json true or false and returns the value.

Results

These are the results from running the benchmarks 10x and using benchstat to compare each package to rjson. You can run them yourself by running script/compbench.

encoding_json

fastjson

gjson

jsoniter

jsonparser

goccyjson

simdjson