pquerna / ffjson

faster JSON serialization for Go

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

performance issue

jiacai2050 opened this issue · comments

type Demo struct {
	A int    `json:"a,omitempty"`
	B string `json:"b,omitempty"`

}

func BenchmarkJsoncost(b *testing.B) {
	d := Demo{
		A: 1,
		B: "abc",
	}

	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		_, err := json.Marshal(d)
		if err != nil {
			b.Errorf("marshal failed: %v", err)
		}
	}
}

go test -run ^NOTHING -bench Jsoncost$ -v

goos: darwin
goarch: amd64
pkg: go-app/basic
BenchmarkJsoncost-8      5000000               318 ns/op              64 B/op          2 allocs/op
PASS

Then, I use ffjson to generate custom MarshalJSON for Demo struct, update json.Marshal(d) to ffjson.Marshal(d), run benchmark again

goos: darwin
goarch: amd64
pkg: go-app/basic
BenchmarkJsoncost-8      5000000               355 ns/op              64 B/op          2 allocs/op
PASS

It seems ffjson is slower than encoding/json, is there anything I'm missing ?

I haven't used ffjson in a long time so I might be wrong, but this is the only way I could get your code fast:

func BenchmarkFFJson(b *testing.B) {
  d := Demo{
    A: 1,
    B: "asd",
  }

  buf := &fflib.Buffer{}
  for i := 0; i < b.N; i++ {
    if err := d.MarshalJSONBuf(buf); err != nil {
      panic(err)
    }
    _ = buf.Bytes()

    buf.Reset()
  }
}

I also had to apply this patch to get ffjson down to 0 allocations: https://gist.github.com/erikdubbelboer/898d219bbc997ab1e9aeee2d64aafa04
It seems like ffjson isn't doing it's best to get hot path allocations down to 0. @pquerna let me know if you want me to make a pull request for this?

The result:

BenchmarkEncodingJson-16    	 4652290       249 ns/op	64 B/op	 2 allocs/op
BenchmarkFFJson-16          	13343437      90.7 ns/op	 0 B/op	 0 allocs/op

Hi @erikdubbelboer,
convert []byte to string no longer require SliceHeader, just *(*string)(unsafe.Pointer(&bs)) is fine.

After dig into this more, I compare ffjson/easyjson/jsoniter, it's surprising ffjson is the slowest, with highest allocs.

BenchmarkJsoncost/std-8                  1000000              1052 ns/op             240 B/op          4 allocs/op
BenchmarkJsoncost/jsoniter-8             1000000              1268 ns/op             272 B/op          5 allocs/op
BenchmarkJsoncost/easyjson-8             2000000               629 ns/op             336 B/op          4 allocs/op
BenchmarkJsoncost/ffjson-8               1000000              1044 ns/op             480 B/op          7 allocs/op

repo for this benchmark:

Correct but this is to convert a string to a []byte which does require SliceHeader as you need to set the capacity which a string doesn't have in it's header.

I always use easyjson, that's why I said I haven't used ffjson in a long time.

if convert []byte to string, *(*[]byte)(unsafe.Pointer(&s)) would be fine IMO.

That will only work in cases where you never look at the capacity of the returned slice. If you do something that looks at the capacity it will fail horribly as it will use the memory after the string header as capacity and you have on idea what is stored there.

I got your point, thanks for your explanation.