]> Cypherpunks.ru repositories - gostls13.git/commit
encoding/json: rely on reflect.Value.Grow
authorJoe Tsai <joetsai@digital-static.net>
Thu, 23 Feb 2023 21:32:10 +0000 (13:32 -0800)
committerGopher Robot <gobot@golang.org>
Mon, 27 Feb 2023 11:58:36 +0000 (11:58 +0000)
commitac27b4dd1d72bd6467bf7bfa8bc77a1522efd4cc
treefbcf278517ba19c1b246464420d50a7216771f36
parent0d52401e2380125615d4a77df31498ce7fbd3b7f
encoding/json: rely on reflect.Value.Grow

The Grow method is generally a more efficient way to grow a slice.
The older approach of using reflect.MakeSlice has to
waste effort zeroing the elements overwritten by the older slice
and has to allocate the slice header on the heap.

Performance:

name                old time/op    new time/op    delta
CodeDecoder         2.41ms ± 2%    2.42ms ± 2%    ~
CodeUnmarshal       3.12ms ± 3%    3.13ms ± 3%    ~
CodeUnmarshalReuse  2.49ms ± 3%    2.52ms ± 3%    ~

name                 old alloc/op  new alloc/op   delta
CodeDecoder         2.00MB ± 1%    1.99MB ± 1%    ~
CodeUnmarshal       3.05MB ± 0%    2.92MB ± 0%    -4.23%
CodeUnmarshalReuse  1.68MB ± 0%    1.68MB ± 0%    -0.32%

name                old allocs/op  new allocs/op  delta
CodeDecoder         77.1k ± 0%     77.0k ± 0%     -0.09%
CodeUnmarshal       92.7k ± 0%     91.3k ± 0%     -1.47%
CodeUnmarshalReuse  77.1k ± 0%     77.0k ± 0%     -0.07%

The Code benchmarks (which are the only ones that uses slices)
are largely unaffected. There is a slight reduction in allocations.

A histogram of slice lengths from the Code testdata is as follows:

   ≤1: 392
   ≤2: 256
   ≤4: 252
   ≤8: 152
  ≤16: 126
  ≤32: 78
  ≤64: 62
 ≤128: 46
 ≤256: 18
 ≤512: 10
≤1024: 8

A bulk majority of slice lengths are 8 elements or under.
Use of reflect.Value.Grow performs better for larger slices since
it can avoid the zeroing of memory and has a faster growth rate.
However, Grow grows starting from 1 element,
with a 2x growth rate until some threshold (currently 512),
Starting from 1 ensures better utilization of the heap,
but at the cost of more frequent regrowth early on.

In comparison, the previous logic always started
with a minimum of 4 elements, which leads to a wasted capacity
of 75% for the highly frequent case of a single element slice.
The older code always had a growth rate of 1.5x,
and so wastes less memory for number of elements below 512.

All in all, there are too many factors that hurt or help performance.
Rergardless, the simplicity of favoring reflect.Value.Grow
over manually managing growth rates is a welcome simplification.

Change-Id: I62868a7f112ece3c2da3b4f6bdf74d397110243c
Reviewed-on: https://go-review.googlesource.com/c/go/+/471175
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
src/encoding/json/decode.go