From ac27b4dd1d72bd6467bf7bfa8bc77a1522efd4cc Mon Sep 17 00:00:00 2001
From: Joe Tsai <joetsai@digital-static.net>
Date: Thu, 23 Feb 2023 13:32:10 -0800
Subject: [PATCH] encoding/json: rely on reflect.Value.Grow
MIME-Version: 1.0
Content-Type: text/plain; charset=utf8
Content-Transfer-Encoding: 8bit

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 | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/src/encoding/json/decode.go b/src/encoding/json/decode.go
index 01af489b56..7ad66cfeb6 100644
--- a/src/encoding/json/decode.go
+++ b/src/encoding/json/decode.go
@@ -540,17 +540,10 @@ func (d *decodeState) array(v reflect.Value) error {
 			break
 		}
 
-		// Get element of array, growing if necessary.
+		// Expand slice length, growing the slice if necessary.
 		if v.Kind() == reflect.Slice {
-			// Grow slice if necessary
 			if i >= v.Cap() {
-				newcap := v.Cap() + v.Cap()/2
-				if newcap < 4 {
-					newcap = 4
-				}
-				newv := reflect.MakeSlice(v.Type(), v.Len(), newcap)
-				reflect.Copy(newv, v)
-				v.Set(newv)
+				v.Grow(1)
 			}
 			if i >= v.Len() {
 				v.SetLen(i + 1)
-- 
2.48.1