encoding/json: marshaling RawMessage has poor performance

[rittneje]

What version of Go are you using (go version)?

$ go version
go version go1.12.6 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jrittner/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jrittner/go-workspace"
GOPROXY=""
GORACE=""
GOROOT="/home/jrittner/go"
GOTMPDIR=""
GOTOOLDIR="/home/jrittner/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build506812392=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Ran a benchmark to compare marshaling a json.RawMessage, a string and a []byte.

package jsontest

import (
	"encoding/json"
	"testing"
)

const msg = `{"a":"aaaaaaa","b":{"c":["d","e"]}}`

var benchmarkResult interface{}

func BenchmarkRawMessage(b *testing.B) {
	x := json.RawMessage(msg)
	for i := 0; i < b.N; i++ {
		j, err := json.Marshal(x)
		if err != nil {
			b.Fatal(err)
		}
		benchmarkResult = j
	}
}

func BenchmarkString(b *testing.B) {
	x := msg
	for i := 0; i < b.N; i++ {
		j, err := json.Marshal(x)
		if err != nil {
			b.Fatal(err)
		}
		benchmarkResult = j
	}
}

func BenchmarkBytes(b *testing.B) {
	x := []byte(msg)
	for i := 0; i < b.N; i++ {
		j, err := json.Marshal(x)
		if err != nil {
			b.Fatal(err)
		}
		benchmarkResult = j
	}
}

What did you expect to see?

I expected marshaling a json.RawMessage to have the best performance of the three, since it should be a no-op.

What did you see instead?

It is 2 times slower than marshaling a string, and 3 times slower than marshaling a []byte.

BenchmarkRawMessage-2 1000000 1513 ns/op 232 B/op 7 allocs/op
BenchmarkString-2 2000000 869 ns/op 112 B/op 3 allocs/op
BenchmarkBytes-2 3000000 561 ns/op 128 B/op 3 allocs/op

[rittneje]

Investigating further, I believe the slowdown is caused by it trying to unnecessarily compact/validate the json.

go/src/encoding/json/encode.go

Line 456 in 2d6ee6e

err = compact(&e.Buffer, b, opts.escapeHTML)

Replacing this with e.Buffer.Write(b) yields much better performance - 477 ns/op.

[agnivade]

@mvdan @dsnet

[dsnet]

trying to unnecessarily compact/validate the json

In some applications, this may be considered true, but as a general principle, the encoding/json package strives for correctness first over performance. We can speed up the implementation of compact, but we can't just trivially avoid the call here.

[rittneje]

As far as I can tell, compact would only accomplish anything if you had a buggy json.Marshaler implementation. In all the years I've used Go, that has never happened, so I honestly cannot see any justification for this performance hit. It would be nice if there was at least an option on json.Encoder to say "I trust the output of all json.Marshalers to be correct, do not attempt to compact/validate it." (On that note, it occurs to me that there is no way for the encoder options to actually get passed into a custom MarshalJSON method. https://play.golang.org/p/b_DZHIrABif)

[dsnet]

In all the years I've used Go, that has never happened, so I honestly cannot see any justification for this performance hit.

Earlier I said: "In some applications, this may be considered true". I don't doubt that this is probably true of your use case. However, it is the current behavior and we can't just remove it as some are relying on this property. Keep in mind that compact does more than simply validate, but also enforces consistent whitespace (or rather lack of) in all outputs.

On that note, it occurs to me that there is no way for the encoder options to actually get passed into a custom MarshalJSON method

Yes. This is a problem that I've written about before regarding encoding/json. In my opinion, this is the primary reason that an option like what you're requesting is hard to fit into the existing API and its current behaviors.

There are many reasonable features to add to encoding/json in isolation, but the problem is that none (or very few) of them operate orthogonally with the existing features.

[mvdan]

I'd suggest investigating ways to optimize the current code without changing the API nor adding any options. If it's still too slow, perhaps file a proposal to change the API.

My thinking is similar to @dsnet's; encoding/json values correctness above performance, so any proposed changes to change the package's API should be well thought out.

[qingyu31]

I'd suggest investigating ways to optimize the current code without changing the API nor adding any options. If it's still too slow, perhaps file a proposal to change the API.

My thinking is similar to @dsnet's; encoding/json values correctness above performance, so any proposed changes to change the package's API should be well thought out.

I've got same problem when I analysis performance of my application. Is it not ok to add options to encOpts?

[gopherbot]

Change https://golang.org/cl/205018 mentions this issue: encoding/json: prevent compact twice to improve precomputed performance.

[dsnet]

Hi all, we kicked off a discussion for a possible "encoding/json/v2" package that addresses the spirit of this proposal.

The prototype v2 implementation has a better parser, able to verify and reformat the result of a MarshalJSON method call much fater. See https://github.com/go-json-experiment/jsonbench#rawvalue-types, which shows that v2 is between 3.6x to 9.1x faster for this situation.