go/src/encoding/json/encode.go

1284 lines
36 KiB
Go
Raw Normal View History

// Copyright 2010 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Package json implements encoding and decoding of JSON as defined in
// RFC 7159. The mapping between JSON and Go values is described
// in the documentation for the Marshal and Unmarshal functions.
//
// See "JSON and Go" for an introduction to this package:
// https://golang.org/doc/articles/json_and_go.html
package json
import (
"bytes"
"encoding"
"encoding/base64"
"fmt"
"math"
"reflect"
"sort"
"strconv"
"strings"
"sync"
"unicode"
"unicode/utf8"
)
// Marshal returns the JSON encoding of v.
//
// Marshal traverses the value v recursively.
// If an encountered value implements the Marshaler interface
// and is not a nil pointer, Marshal calls its MarshalJSON method
// to produce JSON. If no MarshalJSON method is present but the
// value implements encoding.TextMarshaler instead, Marshal calls
// its MarshalText method and encodes the result as a JSON string.
// The nil pointer exception is not strictly necessary
// but mimics a similar, necessary exception in the behavior of
// UnmarshalJSON.
//
// Otherwise, Marshal uses the following type-dependent default encodings:
//
// Boolean values encode as JSON booleans.
//
// Floating point, integer, and Number values encode as JSON numbers.
// NaN and +/-Inf values will return an [UnsupportedValueError].
//
// String values encode as JSON strings coerced to valid UTF-8,
// replacing invalid bytes with the Unicode replacement rune.
// So that the JSON will be safe to embed inside HTML <script> tags,
// the string is encoded using HTMLEscape,
// which replaces "<", ">", "&", U+2028, and U+2029 are escaped
// to "\u003c","\u003e", "\u0026", "\u2028", and "\u2029".
// This replacement can be disabled when using an Encoder,
// by calling SetEscapeHTML(false).
//
// Array and slice values encode as JSON arrays, except that
// []byte encodes as a base64-encoded string, and a nil slice
// encodes as the null JSON value.
//
// Struct values encode as JSON objects.
// Each exported struct field becomes a member of the object, using the
// field name as the object key, unless the field is omitted for one of the
// reasons given below.
//
// The encoding of each struct field can be customized by the format string
// stored under the "json" key in the struct field's tag.
// The format string gives the name of the field, possibly followed by a
// comma-separated list of options. The name may be empty in order to
// specify options without overriding the default field name.
//
// The "omitempty" option specifies that the field should be omitted
// from the encoding if the field has an empty value, defined as
// false, 0, a nil pointer, a nil interface value, and any empty array,
// slice, map, or string.
//
// As a special case, if the field tag is "-", the field is always omitted.
// Note that a field with name "-" can still be generated using the tag "-,".
//
// Examples of struct field tags and their meanings:
//
// // Field appears in JSON as key "myName".
// Field int `json:"myName"`
//
// // Field appears in JSON as key "myName" and
// // the field is omitted from the object if its value is empty,
// // as defined above.
// Field int `json:"myName,omitempty"`
//
// // Field appears in JSON as key "Field" (the default), but
// // the field is skipped if empty.
// // Note the leading comma.
// Field int `json:",omitempty"`
//
// // Field is ignored by this package.
// Field int `json:"-"`
//
// // Field appears in JSON as key "-".
// Field int `json:"-,"`
//
// The "string" option signals that a field is stored as JSON inside a
// JSON-encoded string. It applies only to fields of string, floating point,
// integer, or boolean types. This extra level of encoding is sometimes used
// when communicating with JavaScript programs:
//
// Int64String int64 `json:",string"`
//
// The key name will be used if it's a non-empty string consisting of
// only Unicode letters, digits, and ASCII punctuation except quotation
// marks, backslash, and comma.
//
// Anonymous struct fields are usually marshaled as if their inner exported fields
// were fields in the outer struct, subject to the usual Go visibility rules amended
// as described in the next paragraph.
// An anonymous struct field with a name given in its JSON tag is treated as
// having that name, rather than being anonymous.
// An anonymous struct field of interface type is treated the same as having
// that type as its name, rather than being anonymous.
//
// The Go visibility rules for struct fields are amended for JSON when
// deciding which field to marshal or unmarshal. If there are
// multiple fields at the same level, and that level is the least
// nested (and would therefore be the nesting level selected by the
// usual Go rules), the following extra rules apply:
//
// 1) Of those fields, if any are JSON-tagged, only tagged fields are considered,
// even if there are multiple untagged fields that would otherwise conflict.
//
// 2) If there is exactly one field (tagged or not according to the first rule), that is selected.
//
// 3) Otherwise there are multiple fields, and all are ignored; no error occurs.
//
// Handling of anonymous struct fields is new in Go 1.1.
// Prior to Go 1.1, anonymous struct fields were ignored. To force ignoring of
// an anonymous struct field in both current and earlier versions, give the field
// a JSON tag of "-".
//
// Map values encode as JSON objects. The map's key type must either be a
// string, an integer type, or implement encoding.TextMarshaler. The map keys
// are sorted and used as JSON object keys by applying the following rules,
// subject to the UTF-8 coercion described for string values above:
// - keys of any string type are used directly
// - encoding.TextMarshalers are marshaled
// - integer keys are converted to strings
//
// Pointer values encode as the value pointed to.
// A nil pointer encodes as the null JSON value.
//
// Interface values encode as the value contained in the interface.
// A nil interface value encodes as the null JSON value.
//
// Channel, complex, and function values cannot be encoded in JSON.
// Attempting to encode such a value causes Marshal to return
// an UnsupportedTypeError.
//
// JSON cannot represent cyclic data structures and Marshal does not
// handle them. Passing cyclic structures to Marshal will result in
encoding/json: error when encoding a pointer cycle Otherwise we'd panic with a stack overflow. Most programs are in control of the data being encoded and can ensure there are no cycles, but sometimes it's not that simple. For example, running a user's html template with script tags can easily result in crashes if the user can find a pointer cycle. Adding the checks via a map to every ptrEncoder.encode call slowed down the benchmarks below by a noticeable 13%. Instead, only start doing the relatively expensive pointer cycle checks if we're many levels of pointers deep in an encode state. A threshold of 1000 is small enough to capture pointer cycles before they're a problem (the goroutine stack limit is currently 1GB, and I needed close to a million levels to reach it). Yet it's large enough that reasonable uses of the json encoder only see a tiny 1% slow-down due to the added ptrLevel field and check. name old time/op new time/op delta CodeEncoder-8 2.34ms ± 1% 2.37ms ± 0% +1.05% (p=0.000 n=10+10) CodeMarshal-8 2.42ms ± 1% 2.44ms ± 0% +1.10% (p=0.000 n=10+10) name old speed new speed delta CodeEncoder-8 829MB/s ± 1% 820MB/s ± 0% -1.04% (p=0.000 n=10+10) CodeMarshal-8 803MB/s ± 1% 795MB/s ± 0% -1.09% (p=0.000 n=10+10) name old alloc/op new alloc/op delta CodeEncoder-8 43.1kB ± 8% 42.5kB ±10% ~ (p=0.989 n=10+10) CodeMarshal-8 1.99MB ± 0% 1.99MB ± 0% ~ (p=0.254 n=9+6) name old allocs/op new allocs/op delta CodeEncoder-8 0.00 0.00 ~ (all equal) CodeMarshal-8 1.00 ± 0% 1.00 ± 0% ~ (all equal) Finally, add a few tests to ensure that the code handles the edge cases properly. Fixes #10769. Change-Id: I73d48e0cf6ea140127ea031f2dbae6e6a55e58b8 Reviewed-on: https://go-review.googlesource.com/c/go/+/187920 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com> Reviewed-by: Andrew Bonventre <andybons@golang.org>
2019-07-28 20:16:14 -07:00
// an error.
func Marshal(v any) ([]byte, error) {
e := newEncodeState()
encoding/json: give it a chance to put encodeState back in pool when error occurs name old time/op new time/op delta CodeEncoderError-10 688µs ± 8% 496µs ±15% -27.92% (p=0.000 n=10+9) CodeMarshalError-10 747µs ± 6% 546µs ± 4% -26.86% (p=0.000 n=10+10) MarshalBytesError/32-10 284µs ± 2% 273µs ± 1% -3.84% (p=0.000 n=10+10) MarshalBytesError/256-10 281µs ± 2% 278µs ± 4% ~ (p=0.053 n=9+10) MarshalBytesError/4096-10 290µs ± 1% 279µs ± 3% -3.52% (p=0.000 n=10+10) name old speed new speed delta CodeEncoderError-10 2.83GB/s ± 8% 3.84GB/s ±20% +36.03% (p=0.000 n=10+10) CodeMarshalError-10 2.60GB/s ± 5% 3.56GB/s ± 4% +36.61% (p=0.000 n=10+10) name old alloc/op new alloc/op delta CodeEncoderError-10 4.05MB ± 1% 0.00MB ± 1% -100.00% (p=0.000 n=10+9) CodeMarshalError-10 6.05MB ± 0% 1.99MB ± 1% -67.13% (p=0.000 n=10+10) MarshalBytesError/32-10 66.0kB ± 0% 0.2kB ± 0% -99.67% (p=0.000 n=9+8) MarshalBytesError/256-10 50.1kB ± 0% 0.9kB ± 0% -98.23% (p=0.000 n=9+9) MarshalBytesError/4096-10 87.4kB ± 0% 7.5kB ± 0% -91.47% (p=0.000 n=8+10) name old allocs/op new allocs/op delta CodeEncoderError-10 25.0 ± 0% 4.0 ± 0% -84.00% (p=0.000 n=9+10) CodeMarshalError-10 27.0 ± 0% 6.0 ± 0% -77.78% (p=0.000 n=10+10) MarshalBytesError/32-10 18.0 ± 0% 5.0 ± 0% -72.22% (p=0.000 n=10+10) MarshalBytesError/256-10 17.0 ± 0% 6.0 ± 0% -64.71% (p=0.000 n=10+10) MarshalBytesError/4096-10 16.0 ± 0% 6.0 ± 0% -62.50% (p=0.000 n=10+10) Change-Id: I48070bb05f55707251c694e40d2570403bbf61f8 Reviewed-on: https://go-review.googlesource.com/c/go/+/423694 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-08-14 02:29:33 +08:00
defer encodeStatePool.Put(e)
err := e.marshal(v, encOpts{escapeHTML: true})
if err != nil {
return nil, err
}
buf := append([]byte(nil), e.Bytes()...)
return buf, nil
}
// MarshalIndent is like Marshal but applies Indent to format the output.
// Each JSON element in the output will begin on a new line beginning with prefix
// followed by one or more copies of indent according to the indentation nesting.
func MarshalIndent(v any, prefix, indent string) ([]byte, error) {
b, err := Marshal(v)
if err != nil {
return nil, err
}
b2 := make([]byte, 0, indentGrowthFactor*len(b))
b2, err = appendIndent(b2, b, prefix, indent)
if err != nil {
return nil, err
}
return b2, nil
}
// Marshaler is the interface implemented by types that
// can marshal themselves into valid JSON.
type Marshaler interface {
MarshalJSON() ([]byte, error)
}
// An UnsupportedTypeError is returned by Marshal when attempting
// to encode an unsupported value type.
type UnsupportedTypeError struct {
Type reflect.Type
}
func (e *UnsupportedTypeError) Error() string {
return "json: unsupported type: " + e.Type.String()
}
// An UnsupportedValueError is returned by Marshal when attempting
// to encode an unsupported value.
type UnsupportedValueError struct {
Value reflect.Value
Str string
}
func (e *UnsupportedValueError) Error() string {
return "json: unsupported value: " + e.Str
}
// Before Go 1.2, an InvalidUTF8Error was returned by Marshal when
// attempting to encode a string value with invalid UTF-8 sequences.
// As of Go 1.2, Marshal instead coerces the string to valid UTF-8 by
// replacing invalid bytes with the Unicode replacement rune U+FFFD.
//
// Deprecated: No longer used; kept for compatibility.
type InvalidUTF8Error struct {
S string // the whole string value that caused the error
}
func (e *InvalidUTF8Error) Error() string {
return "json: invalid UTF-8 in string: " + strconv.Quote(e.S)
}
// A MarshalerError represents an error from calling a MarshalJSON or MarshalText method.
type MarshalerError struct {
Type reflect.Type
Err error
sourceFunc string
}
func (e *MarshalerError) Error() string {
srcFunc := e.sourceFunc
if srcFunc == "" {
srcFunc = "MarshalJSON"
}
return "json: error calling " + srcFunc +
" for type " + e.Type.String() +
": " + e.Err.Error()
}
// Unwrap returns the underlying error.
func (e *MarshalerError) Unwrap() error { return e.Err }
var hex = "0123456789abcdef"
// An encodeState encodes JSON into a bytes.Buffer.
type encodeState struct {
bytes.Buffer // accumulated output
encoding/json: error when encoding a pointer cycle Otherwise we'd panic with a stack overflow. Most programs are in control of the data being encoded and can ensure there are no cycles, but sometimes it's not that simple. For example, running a user's html template with script tags can easily result in crashes if the user can find a pointer cycle. Adding the checks via a map to every ptrEncoder.encode call slowed down the benchmarks below by a noticeable 13%. Instead, only start doing the relatively expensive pointer cycle checks if we're many levels of pointers deep in an encode state. A threshold of 1000 is small enough to capture pointer cycles before they're a problem (the goroutine stack limit is currently 1GB, and I needed close to a million levels to reach it). Yet it's large enough that reasonable uses of the json encoder only see a tiny 1% slow-down due to the added ptrLevel field and check. name old time/op new time/op delta CodeEncoder-8 2.34ms ± 1% 2.37ms ± 0% +1.05% (p=0.000 n=10+10) CodeMarshal-8 2.42ms ± 1% 2.44ms ± 0% +1.10% (p=0.000 n=10+10) name old speed new speed delta CodeEncoder-8 829MB/s ± 1% 820MB/s ± 0% -1.04% (p=0.000 n=10+10) CodeMarshal-8 803MB/s ± 1% 795MB/s ± 0% -1.09% (p=0.000 n=10+10) name old alloc/op new alloc/op delta CodeEncoder-8 43.1kB ± 8% 42.5kB ±10% ~ (p=0.989 n=10+10) CodeMarshal-8 1.99MB ± 0% 1.99MB ± 0% ~ (p=0.254 n=9+6) name old allocs/op new allocs/op delta CodeEncoder-8 0.00 0.00 ~ (all equal) CodeMarshal-8 1.00 ± 0% 1.00 ± 0% ~ (all equal) Finally, add a few tests to ensure that the code handles the edge cases properly. Fixes #10769. Change-Id: I73d48e0cf6ea140127ea031f2dbae6e6a55e58b8 Reviewed-on: https://go-review.googlesource.com/c/go/+/187920 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com> Reviewed-by: Andrew Bonventre <andybons@golang.org>
2019-07-28 20:16:14 -07:00
// Keep track of what pointers we've seen in the current recursive call
// path, to avoid cycles that could lead to a stack overflow. Only do
// the relatively expensive map operations if ptrLevel is larger than
// startDetectingCyclesAfter, so that we skip the work if we're within a
// reasonable amount of nested pointers deep.
ptrLevel uint
ptrSeen map[any]struct{}
}
encoding/json: error when encoding a pointer cycle Otherwise we'd panic with a stack overflow. Most programs are in control of the data being encoded and can ensure there are no cycles, but sometimes it's not that simple. For example, running a user's html template with script tags can easily result in crashes if the user can find a pointer cycle. Adding the checks via a map to every ptrEncoder.encode call slowed down the benchmarks below by a noticeable 13%. Instead, only start doing the relatively expensive pointer cycle checks if we're many levels of pointers deep in an encode state. A threshold of 1000 is small enough to capture pointer cycles before they're a problem (the goroutine stack limit is currently 1GB, and I needed close to a million levels to reach it). Yet it's large enough that reasonable uses of the json encoder only see a tiny 1% slow-down due to the added ptrLevel field and check. name old time/op new time/op delta CodeEncoder-8 2.34ms ± 1% 2.37ms ± 0% +1.05% (p=0.000 n=10+10) CodeMarshal-8 2.42ms ± 1% 2.44ms ± 0% +1.10% (p=0.000 n=10+10) name old speed new speed delta CodeEncoder-8 829MB/s ± 1% 820MB/s ± 0% -1.04% (p=0.000 n=10+10) CodeMarshal-8 803MB/s ± 1% 795MB/s ± 0% -1.09% (p=0.000 n=10+10) name old alloc/op new alloc/op delta CodeEncoder-8 43.1kB ± 8% 42.5kB ±10% ~ (p=0.989 n=10+10) CodeMarshal-8 1.99MB ± 0% 1.99MB ± 0% ~ (p=0.254 n=9+6) name old allocs/op new allocs/op delta CodeEncoder-8 0.00 0.00 ~ (all equal) CodeMarshal-8 1.00 ± 0% 1.00 ± 0% ~ (all equal) Finally, add a few tests to ensure that the code handles the edge cases properly. Fixes #10769. Change-Id: I73d48e0cf6ea140127ea031f2dbae6e6a55e58b8 Reviewed-on: https://go-review.googlesource.com/c/go/+/187920 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com> Reviewed-by: Andrew Bonventre <andybons@golang.org>
2019-07-28 20:16:14 -07:00
const startDetectingCyclesAfter = 1000
var encodeStatePool sync.Pool
func newEncodeState() *encodeState {
if v := encodeStatePool.Get(); v != nil {
e := v.(*encodeState)
e.Reset()
encoding/json: error when encoding a pointer cycle Otherwise we'd panic with a stack overflow. Most programs are in control of the data being encoded and can ensure there are no cycles, but sometimes it's not that simple. For example, running a user's html template with script tags can easily result in crashes if the user can find a pointer cycle. Adding the checks via a map to every ptrEncoder.encode call slowed down the benchmarks below by a noticeable 13%. Instead, only start doing the relatively expensive pointer cycle checks if we're many levels of pointers deep in an encode state. A threshold of 1000 is small enough to capture pointer cycles before they're a problem (the goroutine stack limit is currently 1GB, and I needed close to a million levels to reach it). Yet it's large enough that reasonable uses of the json encoder only see a tiny 1% slow-down due to the added ptrLevel field and check. name old time/op new time/op delta CodeEncoder-8 2.34ms ± 1% 2.37ms ± 0% +1.05% (p=0.000 n=10+10) CodeMarshal-8 2.42ms ± 1% 2.44ms ± 0% +1.10% (p=0.000 n=10+10) name old speed new speed delta CodeEncoder-8 829MB/s ± 1% 820MB/s ± 0% -1.04% (p=0.000 n=10+10) CodeMarshal-8 803MB/s ± 1% 795MB/s ± 0% -1.09% (p=0.000 n=10+10) name old alloc/op new alloc/op delta CodeEncoder-8 43.1kB ± 8% 42.5kB ±10% ~ (p=0.989 n=10+10) CodeMarshal-8 1.99MB ± 0% 1.99MB ± 0% ~ (p=0.254 n=9+6) name old allocs/op new allocs/op delta CodeEncoder-8 0.00 0.00 ~ (all equal) CodeMarshal-8 1.00 ± 0% 1.00 ± 0% ~ (all equal) Finally, add a few tests to ensure that the code handles the edge cases properly. Fixes #10769. Change-Id: I73d48e0cf6ea140127ea031f2dbae6e6a55e58b8 Reviewed-on: https://go-review.googlesource.com/c/go/+/187920 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com> Reviewed-by: Andrew Bonventre <andybons@golang.org>
2019-07-28 20:16:14 -07:00
if len(e.ptrSeen) > 0 {
panic("ptrEncoder.encode should have emptied ptrSeen via defers")
}
e.ptrLevel = 0
return e
}
return &encodeState{ptrSeen: make(map[any]struct{})}
}
encoding/json: apply conventional error handling in decoder name old time/op new time/op delta CodeEncoder-12 1.89ms ± 1% 1.91ms ± 0% +1.16% (p=0.000 n=20+19) CodeMarshal-12 2.09ms ± 1% 2.12ms ± 0% +1.63% (p=0.000 n=17+18) CodeDecoder-12 8.43ms ± 1% 8.32ms ± 1% -1.35% (p=0.000 n=18+20) UnicodeDecoder-12 399ns ± 0% 339ns ± 0% -15.00% (p=0.000 n=20+19) DecoderStream-12 281ns ± 1% 231ns ± 0% -17.91% (p=0.000 n=20+16) CodeUnmarshal-12 9.35ms ± 2% 9.15ms ± 2% -2.11% (p=0.000 n=20+20) CodeUnmarshalReuse-12 8.41ms ± 2% 8.29ms ± 2% -1.34% (p=0.000 n=20+20) UnmarshalString-12 81.2ns ± 2% 74.0ns ± 4% -8.89% (p=0.000 n=20+20) UnmarshalFloat64-12 71.1ns ± 2% 64.3ns ± 1% -9.60% (p=0.000 n=20+19) UnmarshalInt64-12 60.6ns ± 2% 53.2ns ± 0% -12.28% (p=0.000 n=18+18) Issue10335-12 96.9ns ± 0% 87.7ns ± 1% -9.52% (p=0.000 n=17+20) Unmapped-12 247ns ± 4% 231ns ± 3% -6.34% (p=0.000 n=20+20) TypeFieldsCache/MissTypes1-12 11.1µs ± 0% 11.1µs ± 0% ~ (p=0.376 n=19+20) TypeFieldsCache/MissTypes10-12 33.9µs ± 0% 33.8µs ± 0% -0.32% (p=0.000 n=18+9) name old speed new speed delta CodeEncoder-12 1.03GB/s ± 1% 1.01GB/s ± 0% -1.15% (p=0.000 n=20+19) CodeMarshal-12 930MB/s ± 1% 915MB/s ± 0% -1.60% (p=0.000 n=17+18) CodeDecoder-12 230MB/s ± 1% 233MB/s ± 1% +1.37% (p=0.000 n=18+20) UnicodeDecoder-12 35.0MB/s ± 0% 41.2MB/s ± 0% +17.60% (p=0.000 n=20+19) CodeUnmarshal-12 208MB/s ± 2% 212MB/s ± 2% +2.16% (p=0.000 n=20+20) name old alloc/op new alloc/op delta Issue10335-12 184B ± 0% 184B ± 0% ~ (all equal) Unmapped-12 216B ± 0% 216B ± 0% ~ (all equal) name old allocs/op new allocs/op delta Issue10335-12 3.00 ± 0% 3.00 ± 0% ~ (all equal) Unmapped-12 4.00 ± 0% 4.00 ± 0% ~ (all equal) Change-Id: I4b1a87a205da2ef9a572f86f85bc833653c61570 Reviewed-on: https://go-review.googlesource.com/98440 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-03-03 15:20:26 +01:00
// jsonError is an error wrapper type for internal use only.
// Panics with errors are wrapped in jsonError so that the top-level recover
// can distinguish intentional panics from this package.
type jsonError struct{ error }
func (e *encodeState) marshal(v any, opts encOpts) (err error) {
defer func() {
if r := recover(); r != nil {
if je, ok := r.(jsonError); ok {
err = je.error
} else {
panic(r)
}
}
}()
e.reflectValue(reflect.ValueOf(v), opts)
return nil
}
// error aborts the encoding by panicking with err wrapped in jsonError.
func (e *encodeState) error(err error) {
panic(jsonError{err})
}
func isEmptyValue(v reflect.Value) bool {
switch v.Kind() {
case reflect.Array, reflect.Map, reflect.Slice, reflect.String:
return v.Len() == 0
case reflect.Bool:
encoding/json: use append-like operations for encoding As part of the effort to rely less on bytes.Buffer, switch most operations to use more natural append-like operations. This makes it easier to swap bytes.Buffer out with a buffer type that only needs to support a minimal subset of operations. As a simplification, we can remove the use of the scratch buffer and use the available capacity of the buffer itself as the scratch. Also, declare an inlineable mayAppendQuote function to conditionally append a double-quote if necessary. Performance: name old time/op new time/op delta CodeEncoder 405µs ± 2% 397µs ± 2% -1.94% (p=0.000 n=20+20) CodeEncoderError 453µs ± 1% 444µs ± 4% -1.83% (p=0.000 n=19+19) CodeMarshal 559µs ± 4% 548µs ± 2% -2.02% (p=0.001 n=19+17) CodeMarshalError 724µs ± 3% 716µs ± 2% -1.13% (p=0.030 n=19+20) EncodeMarshaler 24.9ns ±15% 22.9ns ± 5% ~ (p=0.086 n=20+17) EncoderEncode 14.0ns ±27% 15.0ns ±20% ~ (p=0.365 n=20+20) There is a slight performance gain across the board due to the elimination of the scratch buffer. Appends are done directly into the unused capacity of the underlying buffer, avoiding an additional copy. See #53685 Updates #27735 Change-Id: Icf6d612a7f7a51ecd10097af092762dd1225d49e Reviewed-on: https://go-review.googlesource.com/c/go/+/469558 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 19:05:12 -08:00
return v.Bool() == false
case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
return v.Int() == 0
case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Uintptr:
return v.Uint() == 0
case reflect.Float32, reflect.Float64:
return v.Float() == 0
case reflect.Interface, reflect.Pointer:
return v.IsNil()
}
return false
}
func (e *encodeState) reflectValue(v reflect.Value, opts encOpts) {
valueEncoder(v)(e, v, opts)
}
type encOpts struct {
// quoted causes primitive fields to be encoded inside JSON strings.
quoted bool
// escapeHTML causes '<', '>', and '&' to be escaped in JSON strings.
escapeHTML bool
}
type encoderFunc func(e *encodeState, v reflect.Value, opts encOpts)
encoding/json: replace encoderCache RWMutex with a sync.Map This provides a moderate speedup for encoding when using many CPU cores. name old time/op new time/op delta CodeEncoder 14.1ms ±10% 13.5ms ± 4% ~ (p=0.867 n=8+7) CodeEncoder-6 2.58ms ± 8% 2.72ms ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 629µs ± 1% 629µs ± 1% ~ (p=0.867 n=8+7) CodeMarshal 14.9ms ± 5% 14.9ms ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 3.28ms ±11% 3.24ms ±12% ~ (p=0.798 n=8+8) CodeMarshal-48 739µs ± 1% 745µs ± 2% ~ (p=0.328 n=8+8) CodeDecoder 49.7ms ± 4% 49.2ms ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 10.1ms ± 8% 10.4ms ± 3% ~ (p=0.232 n=7+8) CodeDecoder-48 2.60ms ± 3% 2.61ms ± 2% ~ (p=1.000 n=8+8) DecoderStream 352ns ± 5% 344ns ± 4% ~ (p=0.077 n=8+8) DecoderStream-6 485ns ± 8% 503ns ± 6% ~ (p=0.123 n=8+8) DecoderStream-48 522ns ± 7% 520ns ± 5% ~ (p=0.959 n=8+8) CodeUnmarshal 52.2ms ± 5% 54.4ms ±18% ~ (p=0.955 n=7+8) CodeUnmarshal-6 12.4ms ± 6% 12.3ms ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 3.46ms ± 7% 3.40ms ± 9% ~ (p=0.442 n=8+8) CodeUnmarshalReuse 48.9ms ± 6% 50.3ms ± 7% ~ (p=0.279 n=8+8) CodeUnmarshalReuse-6 10.3ms ±11% 10.3ms ±10% ~ (p=0.959 n=8+8) CodeUnmarshalReuse-48 2.68ms ± 3% 2.67ms ± 4% ~ (p=0.878 n=8+8) UnmarshalString 476ns ± 7% 474ns ± 7% ~ (p=0.644 n=8+8) UnmarshalString-6 164ns ± 9% 160ns ±10% ~ (p=0.556 n=8+8) UnmarshalString-48 181ns ± 0% 177ns ± 2% -2.36% (p=0.001 n=7+7) UnmarshalFloat64 414ns ± 4% 418ns ± 4% ~ (p=0.382 n=8+8) UnmarshalFloat64-6 147ns ± 9% 143ns ±16% ~ (p=0.457 n=8+8) UnmarshalFloat64-48 176ns ± 2% 174ns ± 2% ~ (p=0.118 n=8+8) UnmarshalInt64 369ns ± 4% 354ns ± 1% -3.85% (p=0.005 n=8+7) UnmarshalInt64-6 132ns ±11% 132ns ±10% ~ (p=0.982 n=8+8) UnmarshalInt64-48 177ns ± 3% 174ns ± 2% -1.84% (p=0.028 n=8+7) Issue10335 540ns ± 5% 535ns ± 0% ~ (p=0.330 n=7+7) Issue10335-6 159ns ± 8% 164ns ± 8% ~ (p=0.246 n=8+8) Issue10335-48 186ns ± 1% 182ns ± 2% -1.89% (p=0.010 n=8+8) Unmapped 1.74µs ± 2% 1.76µs ± 6% ~ (p=0.181 n=6+8) Unmapped-6 414ns ± 5% 402ns ±10% ~ (p=0.244 n=7+8) Unmapped-48 226ns ± 2% 224ns ± 2% ~ (p=0.144 n=7+8) NumberIsValid 20.1ns ± 4% 19.7ns ± 3% ~ (p=0.204 n=8+8) NumberIsValid-6 20.4ns ± 8% 22.2ns ±16% ~ (p=0.129 n=7+8) NumberIsValid-48 23.1ns ±12% 23.8ns ± 8% ~ (p=0.104 n=8+8) NumberIsValidRegexp 629ns ± 5% 622ns ± 0% ~ (p=0.148 n=7+7) NumberIsValidRegexp-6 757ns ± 2% 725ns ±14% ~ (p=0.351 n=8+7) NumberIsValidRegexp-48 757ns ± 2% 723ns ±13% ~ (p=0.521 n=8+8) SkipValue 13.2ms ± 9% 13.3ms ± 1% ~ (p=0.130 n=8+8) SkipValue-6 15.1ms ±10% 14.8ms ± 2% ~ (p=0.397 n=7+8) SkipValue-48 13.9ms ±12% 14.3ms ± 1% ~ (p=0.694 n=8+7) EncoderEncode 433ns ± 4% 410ns ± 3% -5.48% (p=0.001 n=8+8) EncoderEncode-6 221ns ±15% 75ns ± 5% -66.15% (p=0.000 n=7+8) EncoderEncode-48 161ns ± 4% 19ns ± 7% -88.29% (p=0.000 n=7+8) name old speed new speed delta CodeEncoder 139MB/s ±10% 144MB/s ± 4% ~ (p=0.844 n=8+7) CodeEncoder-6 756MB/s ± 8% 714MB/s ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 3.08GB/s ± 1% 3.09GB/s ± 1% ~ (p=0.867 n=8+7) CodeMarshal 130MB/s ± 5% 130MB/s ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 594MB/s ±10% 601MB/s ±11% ~ (p=0.798 n=8+8) CodeMarshal-48 2.62GB/s ± 1% 2.60GB/s ± 2% ~ (p=0.328 n=8+8) CodeDecoder 39.0MB/s ± 4% 39.5MB/s ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 189MB/s ±13% 187MB/s ± 3% ~ (p=0.505 n=8+8) CodeDecoder-48 746MB/s ± 2% 745MB/s ± 2% ~ (p=1.000 n=8+8) CodeUnmarshal 37.2MB/s ± 5% 35.9MB/s ±16% ~ (p=0.955 n=7+8) CodeUnmarshal-6 157MB/s ± 6% 158MB/s ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 561MB/s ± 7% 572MB/s ±10% ~ (p=0.442 n=8+8) SkipValue 141MB/s ±10% 139MB/s ± 1% ~ (p=0.130 n=8+8) SkipValue-6 131MB/s ± 3% 133MB/s ± 2% ~ (p=0.662 n=6+8) SkipValue-48 138MB/s ±11% 132MB/s ± 1% ~ (p=0.281 n=8+7) name old alloc/op new alloc/op delta CodeEncoder 45.9kB ± 0% 45.9kB ± 0% -0.02% (p=0.002 n=7+8) CodeEncoder-6 55.1kB ± 0% 55.1kB ± 0% -0.01% (p=0.002 n=7+8) CodeEncoder-48 110kB ± 0% 110kB ± 0% -0.00% (p=0.030 n=7+8) CodeMarshal 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-6 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-48 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.001 n=7+8) CodeDecoder 2.28MB ± 5% 2.21MB ± 0% ~ (p=0.257 n=8+7) CodeDecoder-6 2.43MB ±11% 2.51MB ± 0% ~ (p=0.473 n=8+8) CodeDecoder-48 2.93MB ± 0% 2.93MB ± 0% ~ (p=0.554 n=7+8) DecoderStream 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-6 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-48 16.0B ± 0% 16.0B ± 0% ~ (all equal) CodeUnmarshal 3.28MB ± 0% 3.28MB ± 0% ~ (p=1.000 n=7+7) CodeUnmarshal-6 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.593 n=8+8) CodeUnmarshal-48 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.670 n=8+8) CodeUnmarshalReuse 1.87MB ± 0% 1.88MB ± 1% +0.48% (p=0.011 n=7+8) CodeUnmarshalReuse-6 1.90MB ± 1% 1.90MB ± 1% ~ (p=0.589 n=8+8) CodeUnmarshalReuse-48 1.96MB ± 0% 1.96MB ± 0% +0.00% (p=0.002 n=7+8) UnmarshalString 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-6 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-48 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalFloat64 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-6 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-48 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalInt64 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-6 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-48 289B ± 0% 289B ± 0% ~ (all equal) Issue10335 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-6 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-48 312B ± 0% 312B ± 0% ~ (all equal) Unmapped 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-6 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-48 344B ± 0% 344B ± 0% ~ (all equal) NumberIsValid 0.00B 0.00B ~ (all equal) NumberIsValid-6 0.00B 0.00B ~ (all equal) NumberIsValid-48 0.00B 0.00B ~ (all equal) NumberIsValidRegexp 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-6 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-48 0.00B 0.00B ~ (all equal) SkipValue 0.00B 0.00B ~ (all equal) SkipValue-6 0.00B 0.00B ~ (all equal) SkipValue-48 15.0B ±167% 0.0B ~ (p=0.200 n=8+8) EncoderEncode 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-6 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-48 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) name old allocs/op new allocs/op delta CodeEncoder 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeMarshal 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-6 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-48 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeDecoder 89.6k ± 0% 89.5k ± 0% ~ (p=0.154 n=8+7) CodeDecoder-6 89.8k ± 0% 89.9k ± 0% ~ (p=0.467 n=8+8) CodeDecoder-48 90.5k ± 0% 90.5k ± 0% ~ (p=0.533 n=8+7) DecoderStream 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) CodeUnmarshal 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-6 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-48 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshalReuse 89.5k ± 0% 89.6k ± 0% ~ (p=0.246 n=7+8) CodeUnmarshalReuse-6 89.8k ± 0% 89.8k ± 0% ~ (p=1.000 n=8+8) CodeUnmarshalReuse-48 90.5k ± 0% 90.5k ± 0% ~ (all equal) UnmarshalString 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) Issue10335 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-6 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-48 3.00 ± 0% 3.00 ± 0% ~ (all equal) Unmapped 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-6 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-48 4.00 ± 0% 4.00 ± 0% ~ (all equal) NumberIsValid 0.00 0.00 ~ (all equal) NumberIsValid-6 0.00 0.00 ~ (all equal) NumberIsValid-48 0.00 0.00 ~ (all equal) NumberIsValidRegexp 0.00 0.00 ~ (all equal) NumberIsValidRegexp-6 0.00 0.00 ~ (all equal) NumberIsValidRegexp-48 0.00 0.00 ~ (all equal) SkipValue 0.00 0.00 ~ (all equal) SkipValue-6 0.00 0.00 ~ (all equal) SkipValue-48 0.00 0.00 ~ (all equal) EncoderEncode 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) https://perf.golang.org/search?q=upload:20170427.2 updates #17973 updates #18177 Change-Id: I5881c7a2bfad1766e6aa3444bb630883e0be467b Reviewed-on: https://go-review.googlesource.com/41931 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-02-16 17:41:13 -05:00
var encoderCache sync.Map // map[reflect.Type]encoderFunc
func valueEncoder(v reflect.Value) encoderFunc {
if !v.IsValid() {
return invalidValueEncoder
}
return typeEncoder(v.Type())
}
func typeEncoder(t reflect.Type) encoderFunc {
encoding/json: replace encoderCache RWMutex with a sync.Map This provides a moderate speedup for encoding when using many CPU cores. name old time/op new time/op delta CodeEncoder 14.1ms ±10% 13.5ms ± 4% ~ (p=0.867 n=8+7) CodeEncoder-6 2.58ms ± 8% 2.72ms ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 629µs ± 1% 629µs ± 1% ~ (p=0.867 n=8+7) CodeMarshal 14.9ms ± 5% 14.9ms ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 3.28ms ±11% 3.24ms ±12% ~ (p=0.798 n=8+8) CodeMarshal-48 739µs ± 1% 745µs ± 2% ~ (p=0.328 n=8+8) CodeDecoder 49.7ms ± 4% 49.2ms ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 10.1ms ± 8% 10.4ms ± 3% ~ (p=0.232 n=7+8) CodeDecoder-48 2.60ms ± 3% 2.61ms ± 2% ~ (p=1.000 n=8+8) DecoderStream 352ns ± 5% 344ns ± 4% ~ (p=0.077 n=8+8) DecoderStream-6 485ns ± 8% 503ns ± 6% ~ (p=0.123 n=8+8) DecoderStream-48 522ns ± 7% 520ns ± 5% ~ (p=0.959 n=8+8) CodeUnmarshal 52.2ms ± 5% 54.4ms ±18% ~ (p=0.955 n=7+8) CodeUnmarshal-6 12.4ms ± 6% 12.3ms ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 3.46ms ± 7% 3.40ms ± 9% ~ (p=0.442 n=8+8) CodeUnmarshalReuse 48.9ms ± 6% 50.3ms ± 7% ~ (p=0.279 n=8+8) CodeUnmarshalReuse-6 10.3ms ±11% 10.3ms ±10% ~ (p=0.959 n=8+8) CodeUnmarshalReuse-48 2.68ms ± 3% 2.67ms ± 4% ~ (p=0.878 n=8+8) UnmarshalString 476ns ± 7% 474ns ± 7% ~ (p=0.644 n=8+8) UnmarshalString-6 164ns ± 9% 160ns ±10% ~ (p=0.556 n=8+8) UnmarshalString-48 181ns ± 0% 177ns ± 2% -2.36% (p=0.001 n=7+7) UnmarshalFloat64 414ns ± 4% 418ns ± 4% ~ (p=0.382 n=8+8) UnmarshalFloat64-6 147ns ± 9% 143ns ±16% ~ (p=0.457 n=8+8) UnmarshalFloat64-48 176ns ± 2% 174ns ± 2% ~ (p=0.118 n=8+8) UnmarshalInt64 369ns ± 4% 354ns ± 1% -3.85% (p=0.005 n=8+7) UnmarshalInt64-6 132ns ±11% 132ns ±10% ~ (p=0.982 n=8+8) UnmarshalInt64-48 177ns ± 3% 174ns ± 2% -1.84% (p=0.028 n=8+7) Issue10335 540ns ± 5% 535ns ± 0% ~ (p=0.330 n=7+7) Issue10335-6 159ns ± 8% 164ns ± 8% ~ (p=0.246 n=8+8) Issue10335-48 186ns ± 1% 182ns ± 2% -1.89% (p=0.010 n=8+8) Unmapped 1.74µs ± 2% 1.76µs ± 6% ~ (p=0.181 n=6+8) Unmapped-6 414ns ± 5% 402ns ±10% ~ (p=0.244 n=7+8) Unmapped-48 226ns ± 2% 224ns ± 2% ~ (p=0.144 n=7+8) NumberIsValid 20.1ns ± 4% 19.7ns ± 3% ~ (p=0.204 n=8+8) NumberIsValid-6 20.4ns ± 8% 22.2ns ±16% ~ (p=0.129 n=7+8) NumberIsValid-48 23.1ns ±12% 23.8ns ± 8% ~ (p=0.104 n=8+8) NumberIsValidRegexp 629ns ± 5% 622ns ± 0% ~ (p=0.148 n=7+7) NumberIsValidRegexp-6 757ns ± 2% 725ns ±14% ~ (p=0.351 n=8+7) NumberIsValidRegexp-48 757ns ± 2% 723ns ±13% ~ (p=0.521 n=8+8) SkipValue 13.2ms ± 9% 13.3ms ± 1% ~ (p=0.130 n=8+8) SkipValue-6 15.1ms ±10% 14.8ms ± 2% ~ (p=0.397 n=7+8) SkipValue-48 13.9ms ±12% 14.3ms ± 1% ~ (p=0.694 n=8+7) EncoderEncode 433ns ± 4% 410ns ± 3% -5.48% (p=0.001 n=8+8) EncoderEncode-6 221ns ±15% 75ns ± 5% -66.15% (p=0.000 n=7+8) EncoderEncode-48 161ns ± 4% 19ns ± 7% -88.29% (p=0.000 n=7+8) name old speed new speed delta CodeEncoder 139MB/s ±10% 144MB/s ± 4% ~ (p=0.844 n=8+7) CodeEncoder-6 756MB/s ± 8% 714MB/s ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 3.08GB/s ± 1% 3.09GB/s ± 1% ~ (p=0.867 n=8+7) CodeMarshal 130MB/s ± 5% 130MB/s ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 594MB/s ±10% 601MB/s ±11% ~ (p=0.798 n=8+8) CodeMarshal-48 2.62GB/s ± 1% 2.60GB/s ± 2% ~ (p=0.328 n=8+8) CodeDecoder 39.0MB/s ± 4% 39.5MB/s ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 189MB/s ±13% 187MB/s ± 3% ~ (p=0.505 n=8+8) CodeDecoder-48 746MB/s ± 2% 745MB/s ± 2% ~ (p=1.000 n=8+8) CodeUnmarshal 37.2MB/s ± 5% 35.9MB/s ±16% ~ (p=0.955 n=7+8) CodeUnmarshal-6 157MB/s ± 6% 158MB/s ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 561MB/s ± 7% 572MB/s ±10% ~ (p=0.442 n=8+8) SkipValue 141MB/s ±10% 139MB/s ± 1% ~ (p=0.130 n=8+8) SkipValue-6 131MB/s ± 3% 133MB/s ± 2% ~ (p=0.662 n=6+8) SkipValue-48 138MB/s ±11% 132MB/s ± 1% ~ (p=0.281 n=8+7) name old alloc/op new alloc/op delta CodeEncoder 45.9kB ± 0% 45.9kB ± 0% -0.02% (p=0.002 n=7+8) CodeEncoder-6 55.1kB ± 0% 55.1kB ± 0% -0.01% (p=0.002 n=7+8) CodeEncoder-48 110kB ± 0% 110kB ± 0% -0.00% (p=0.030 n=7+8) CodeMarshal 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-6 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-48 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.001 n=7+8) CodeDecoder 2.28MB ± 5% 2.21MB ± 0% ~ (p=0.257 n=8+7) CodeDecoder-6 2.43MB ±11% 2.51MB ± 0% ~ (p=0.473 n=8+8) CodeDecoder-48 2.93MB ± 0% 2.93MB ± 0% ~ (p=0.554 n=7+8) DecoderStream 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-6 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-48 16.0B ± 0% 16.0B ± 0% ~ (all equal) CodeUnmarshal 3.28MB ± 0% 3.28MB ± 0% ~ (p=1.000 n=7+7) CodeUnmarshal-6 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.593 n=8+8) CodeUnmarshal-48 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.670 n=8+8) CodeUnmarshalReuse 1.87MB ± 0% 1.88MB ± 1% +0.48% (p=0.011 n=7+8) CodeUnmarshalReuse-6 1.90MB ± 1% 1.90MB ± 1% ~ (p=0.589 n=8+8) CodeUnmarshalReuse-48 1.96MB ± 0% 1.96MB ± 0% +0.00% (p=0.002 n=7+8) UnmarshalString 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-6 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-48 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalFloat64 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-6 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-48 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalInt64 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-6 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-48 289B ± 0% 289B ± 0% ~ (all equal) Issue10335 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-6 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-48 312B ± 0% 312B ± 0% ~ (all equal) Unmapped 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-6 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-48 344B ± 0% 344B ± 0% ~ (all equal) NumberIsValid 0.00B 0.00B ~ (all equal) NumberIsValid-6 0.00B 0.00B ~ (all equal) NumberIsValid-48 0.00B 0.00B ~ (all equal) NumberIsValidRegexp 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-6 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-48 0.00B 0.00B ~ (all equal) SkipValue 0.00B 0.00B ~ (all equal) SkipValue-6 0.00B 0.00B ~ (all equal) SkipValue-48 15.0B ±167% 0.0B ~ (p=0.200 n=8+8) EncoderEncode 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-6 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-48 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) name old allocs/op new allocs/op delta CodeEncoder 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeMarshal 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-6 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-48 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeDecoder 89.6k ± 0% 89.5k ± 0% ~ (p=0.154 n=8+7) CodeDecoder-6 89.8k ± 0% 89.9k ± 0% ~ (p=0.467 n=8+8) CodeDecoder-48 90.5k ± 0% 90.5k ± 0% ~ (p=0.533 n=8+7) DecoderStream 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) CodeUnmarshal 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-6 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-48 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshalReuse 89.5k ± 0% 89.6k ± 0% ~ (p=0.246 n=7+8) CodeUnmarshalReuse-6 89.8k ± 0% 89.8k ± 0% ~ (p=1.000 n=8+8) CodeUnmarshalReuse-48 90.5k ± 0% 90.5k ± 0% ~ (all equal) UnmarshalString 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) Issue10335 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-6 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-48 3.00 ± 0% 3.00 ± 0% ~ (all equal) Unmapped 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-6 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-48 4.00 ± 0% 4.00 ± 0% ~ (all equal) NumberIsValid 0.00 0.00 ~ (all equal) NumberIsValid-6 0.00 0.00 ~ (all equal) NumberIsValid-48 0.00 0.00 ~ (all equal) NumberIsValidRegexp 0.00 0.00 ~ (all equal) NumberIsValidRegexp-6 0.00 0.00 ~ (all equal) NumberIsValidRegexp-48 0.00 0.00 ~ (all equal) SkipValue 0.00 0.00 ~ (all equal) SkipValue-6 0.00 0.00 ~ (all equal) SkipValue-48 0.00 0.00 ~ (all equal) EncoderEncode 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) https://perf.golang.org/search?q=upload:20170427.2 updates #17973 updates #18177 Change-Id: I5881c7a2bfad1766e6aa3444bb630883e0be467b Reviewed-on: https://go-review.googlesource.com/41931 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-02-16 17:41:13 -05:00
if fi, ok := encoderCache.Load(t); ok {
return fi.(encoderFunc)
}
// To deal with recursive types, populate the map with an
// indirect func before we build it. This type waits on the
// real func (f) to be ready and then calls it. This indirect
// func is only used for recursive types.
encoding/json: replace encoderCache RWMutex with a sync.Map This provides a moderate speedup for encoding when using many CPU cores. name old time/op new time/op delta CodeEncoder 14.1ms ±10% 13.5ms ± 4% ~ (p=0.867 n=8+7) CodeEncoder-6 2.58ms ± 8% 2.72ms ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 629µs ± 1% 629µs ± 1% ~ (p=0.867 n=8+7) CodeMarshal 14.9ms ± 5% 14.9ms ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 3.28ms ±11% 3.24ms ±12% ~ (p=0.798 n=8+8) CodeMarshal-48 739µs ± 1% 745µs ± 2% ~ (p=0.328 n=8+8) CodeDecoder 49.7ms ± 4% 49.2ms ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 10.1ms ± 8% 10.4ms ± 3% ~ (p=0.232 n=7+8) CodeDecoder-48 2.60ms ± 3% 2.61ms ± 2% ~ (p=1.000 n=8+8) DecoderStream 352ns ± 5% 344ns ± 4% ~ (p=0.077 n=8+8) DecoderStream-6 485ns ± 8% 503ns ± 6% ~ (p=0.123 n=8+8) DecoderStream-48 522ns ± 7% 520ns ± 5% ~ (p=0.959 n=8+8) CodeUnmarshal 52.2ms ± 5% 54.4ms ±18% ~ (p=0.955 n=7+8) CodeUnmarshal-6 12.4ms ± 6% 12.3ms ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 3.46ms ± 7% 3.40ms ± 9% ~ (p=0.442 n=8+8) CodeUnmarshalReuse 48.9ms ± 6% 50.3ms ± 7% ~ (p=0.279 n=8+8) CodeUnmarshalReuse-6 10.3ms ±11% 10.3ms ±10% ~ (p=0.959 n=8+8) CodeUnmarshalReuse-48 2.68ms ± 3% 2.67ms ± 4% ~ (p=0.878 n=8+8) UnmarshalString 476ns ± 7% 474ns ± 7% ~ (p=0.644 n=8+8) UnmarshalString-6 164ns ± 9% 160ns ±10% ~ (p=0.556 n=8+8) UnmarshalString-48 181ns ± 0% 177ns ± 2% -2.36% (p=0.001 n=7+7) UnmarshalFloat64 414ns ± 4% 418ns ± 4% ~ (p=0.382 n=8+8) UnmarshalFloat64-6 147ns ± 9% 143ns ±16% ~ (p=0.457 n=8+8) UnmarshalFloat64-48 176ns ± 2% 174ns ± 2% ~ (p=0.118 n=8+8) UnmarshalInt64 369ns ± 4% 354ns ± 1% -3.85% (p=0.005 n=8+7) UnmarshalInt64-6 132ns ±11% 132ns ±10% ~ (p=0.982 n=8+8) UnmarshalInt64-48 177ns ± 3% 174ns ± 2% -1.84% (p=0.028 n=8+7) Issue10335 540ns ± 5% 535ns ± 0% ~ (p=0.330 n=7+7) Issue10335-6 159ns ± 8% 164ns ± 8% ~ (p=0.246 n=8+8) Issue10335-48 186ns ± 1% 182ns ± 2% -1.89% (p=0.010 n=8+8) Unmapped 1.74µs ± 2% 1.76µs ± 6% ~ (p=0.181 n=6+8) Unmapped-6 414ns ± 5% 402ns ±10% ~ (p=0.244 n=7+8) Unmapped-48 226ns ± 2% 224ns ± 2% ~ (p=0.144 n=7+8) NumberIsValid 20.1ns ± 4% 19.7ns ± 3% ~ (p=0.204 n=8+8) NumberIsValid-6 20.4ns ± 8% 22.2ns ±16% ~ (p=0.129 n=7+8) NumberIsValid-48 23.1ns ±12% 23.8ns ± 8% ~ (p=0.104 n=8+8) NumberIsValidRegexp 629ns ± 5% 622ns ± 0% ~ (p=0.148 n=7+7) NumberIsValidRegexp-6 757ns ± 2% 725ns ±14% ~ (p=0.351 n=8+7) NumberIsValidRegexp-48 757ns ± 2% 723ns ±13% ~ (p=0.521 n=8+8) SkipValue 13.2ms ± 9% 13.3ms ± 1% ~ (p=0.130 n=8+8) SkipValue-6 15.1ms ±10% 14.8ms ± 2% ~ (p=0.397 n=7+8) SkipValue-48 13.9ms ±12% 14.3ms ± 1% ~ (p=0.694 n=8+7) EncoderEncode 433ns ± 4% 410ns ± 3% -5.48% (p=0.001 n=8+8) EncoderEncode-6 221ns ±15% 75ns ± 5% -66.15% (p=0.000 n=7+8) EncoderEncode-48 161ns ± 4% 19ns ± 7% -88.29% (p=0.000 n=7+8) name old speed new speed delta CodeEncoder 139MB/s ±10% 144MB/s ± 4% ~ (p=0.844 n=8+7) CodeEncoder-6 756MB/s ± 8% 714MB/s ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 3.08GB/s ± 1% 3.09GB/s ± 1% ~ (p=0.867 n=8+7) CodeMarshal 130MB/s ± 5% 130MB/s ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 594MB/s ±10% 601MB/s ±11% ~ (p=0.798 n=8+8) CodeMarshal-48 2.62GB/s ± 1% 2.60GB/s ± 2% ~ (p=0.328 n=8+8) CodeDecoder 39.0MB/s ± 4% 39.5MB/s ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 189MB/s ±13% 187MB/s ± 3% ~ (p=0.505 n=8+8) CodeDecoder-48 746MB/s ± 2% 745MB/s ± 2% ~ (p=1.000 n=8+8) CodeUnmarshal 37.2MB/s ± 5% 35.9MB/s ±16% ~ (p=0.955 n=7+8) CodeUnmarshal-6 157MB/s ± 6% 158MB/s ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 561MB/s ± 7% 572MB/s ±10% ~ (p=0.442 n=8+8) SkipValue 141MB/s ±10% 139MB/s ± 1% ~ (p=0.130 n=8+8) SkipValue-6 131MB/s ± 3% 133MB/s ± 2% ~ (p=0.662 n=6+8) SkipValue-48 138MB/s ±11% 132MB/s ± 1% ~ (p=0.281 n=8+7) name old alloc/op new alloc/op delta CodeEncoder 45.9kB ± 0% 45.9kB ± 0% -0.02% (p=0.002 n=7+8) CodeEncoder-6 55.1kB ± 0% 55.1kB ± 0% -0.01% (p=0.002 n=7+8) CodeEncoder-48 110kB ± 0% 110kB ± 0% -0.00% (p=0.030 n=7+8) CodeMarshal 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-6 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-48 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.001 n=7+8) CodeDecoder 2.28MB ± 5% 2.21MB ± 0% ~ (p=0.257 n=8+7) CodeDecoder-6 2.43MB ±11% 2.51MB ± 0% ~ (p=0.473 n=8+8) CodeDecoder-48 2.93MB ± 0% 2.93MB ± 0% ~ (p=0.554 n=7+8) DecoderStream 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-6 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-48 16.0B ± 0% 16.0B ± 0% ~ (all equal) CodeUnmarshal 3.28MB ± 0% 3.28MB ± 0% ~ (p=1.000 n=7+7) CodeUnmarshal-6 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.593 n=8+8) CodeUnmarshal-48 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.670 n=8+8) CodeUnmarshalReuse 1.87MB ± 0% 1.88MB ± 1% +0.48% (p=0.011 n=7+8) CodeUnmarshalReuse-6 1.90MB ± 1% 1.90MB ± 1% ~ (p=0.589 n=8+8) CodeUnmarshalReuse-48 1.96MB ± 0% 1.96MB ± 0% +0.00% (p=0.002 n=7+8) UnmarshalString 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-6 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-48 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalFloat64 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-6 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-48 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalInt64 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-6 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-48 289B ± 0% 289B ± 0% ~ (all equal) Issue10335 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-6 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-48 312B ± 0% 312B ± 0% ~ (all equal) Unmapped 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-6 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-48 344B ± 0% 344B ± 0% ~ (all equal) NumberIsValid 0.00B 0.00B ~ (all equal) NumberIsValid-6 0.00B 0.00B ~ (all equal) NumberIsValid-48 0.00B 0.00B ~ (all equal) NumberIsValidRegexp 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-6 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-48 0.00B 0.00B ~ (all equal) SkipValue 0.00B 0.00B ~ (all equal) SkipValue-6 0.00B 0.00B ~ (all equal) SkipValue-48 15.0B ±167% 0.0B ~ (p=0.200 n=8+8) EncoderEncode 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-6 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-48 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) name old allocs/op new allocs/op delta CodeEncoder 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeMarshal 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-6 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-48 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeDecoder 89.6k ± 0% 89.5k ± 0% ~ (p=0.154 n=8+7) CodeDecoder-6 89.8k ± 0% 89.9k ± 0% ~ (p=0.467 n=8+8) CodeDecoder-48 90.5k ± 0% 90.5k ± 0% ~ (p=0.533 n=8+7) DecoderStream 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) CodeUnmarshal 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-6 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-48 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshalReuse 89.5k ± 0% 89.6k ± 0% ~ (p=0.246 n=7+8) CodeUnmarshalReuse-6 89.8k ± 0% 89.8k ± 0% ~ (p=1.000 n=8+8) CodeUnmarshalReuse-48 90.5k ± 0% 90.5k ± 0% ~ (all equal) UnmarshalString 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) Issue10335 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-6 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-48 3.00 ± 0% 3.00 ± 0% ~ (all equal) Unmapped 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-6 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-48 4.00 ± 0% 4.00 ± 0% ~ (all equal) NumberIsValid 0.00 0.00 ~ (all equal) NumberIsValid-6 0.00 0.00 ~ (all equal) NumberIsValid-48 0.00 0.00 ~ (all equal) NumberIsValidRegexp 0.00 0.00 ~ (all equal) NumberIsValidRegexp-6 0.00 0.00 ~ (all equal) NumberIsValidRegexp-48 0.00 0.00 ~ (all equal) SkipValue 0.00 0.00 ~ (all equal) SkipValue-6 0.00 0.00 ~ (all equal) SkipValue-48 0.00 0.00 ~ (all equal) EncoderEncode 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) https://perf.golang.org/search?q=upload:20170427.2 updates #17973 updates #18177 Change-Id: I5881c7a2bfad1766e6aa3444bb630883e0be467b Reviewed-on: https://go-review.googlesource.com/41931 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-02-16 17:41:13 -05:00
var (
wg sync.WaitGroup
f encoderFunc
)
wg.Add(1)
encoding/json: replace encoderCache RWMutex with a sync.Map This provides a moderate speedup for encoding when using many CPU cores. name old time/op new time/op delta CodeEncoder 14.1ms ±10% 13.5ms ± 4% ~ (p=0.867 n=8+7) CodeEncoder-6 2.58ms ± 8% 2.72ms ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 629µs ± 1% 629µs ± 1% ~ (p=0.867 n=8+7) CodeMarshal 14.9ms ± 5% 14.9ms ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 3.28ms ±11% 3.24ms ±12% ~ (p=0.798 n=8+8) CodeMarshal-48 739µs ± 1% 745µs ± 2% ~ (p=0.328 n=8+8) CodeDecoder 49.7ms ± 4% 49.2ms ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 10.1ms ± 8% 10.4ms ± 3% ~ (p=0.232 n=7+8) CodeDecoder-48 2.60ms ± 3% 2.61ms ± 2% ~ (p=1.000 n=8+8) DecoderStream 352ns ± 5% 344ns ± 4% ~ (p=0.077 n=8+8) DecoderStream-6 485ns ± 8% 503ns ± 6% ~ (p=0.123 n=8+8) DecoderStream-48 522ns ± 7% 520ns ± 5% ~ (p=0.959 n=8+8) CodeUnmarshal 52.2ms ± 5% 54.4ms ±18% ~ (p=0.955 n=7+8) CodeUnmarshal-6 12.4ms ± 6% 12.3ms ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 3.46ms ± 7% 3.40ms ± 9% ~ (p=0.442 n=8+8) CodeUnmarshalReuse 48.9ms ± 6% 50.3ms ± 7% ~ (p=0.279 n=8+8) CodeUnmarshalReuse-6 10.3ms ±11% 10.3ms ±10% ~ (p=0.959 n=8+8) CodeUnmarshalReuse-48 2.68ms ± 3% 2.67ms ± 4% ~ (p=0.878 n=8+8) UnmarshalString 476ns ± 7% 474ns ± 7% ~ (p=0.644 n=8+8) UnmarshalString-6 164ns ± 9% 160ns ±10% ~ (p=0.556 n=8+8) UnmarshalString-48 181ns ± 0% 177ns ± 2% -2.36% (p=0.001 n=7+7) UnmarshalFloat64 414ns ± 4% 418ns ± 4% ~ (p=0.382 n=8+8) UnmarshalFloat64-6 147ns ± 9% 143ns ±16% ~ (p=0.457 n=8+8) UnmarshalFloat64-48 176ns ± 2% 174ns ± 2% ~ (p=0.118 n=8+8) UnmarshalInt64 369ns ± 4% 354ns ± 1% -3.85% (p=0.005 n=8+7) UnmarshalInt64-6 132ns ±11% 132ns ±10% ~ (p=0.982 n=8+8) UnmarshalInt64-48 177ns ± 3% 174ns ± 2% -1.84% (p=0.028 n=8+7) Issue10335 540ns ± 5% 535ns ± 0% ~ (p=0.330 n=7+7) Issue10335-6 159ns ± 8% 164ns ± 8% ~ (p=0.246 n=8+8) Issue10335-48 186ns ± 1% 182ns ± 2% -1.89% (p=0.010 n=8+8) Unmapped 1.74µs ± 2% 1.76µs ± 6% ~ (p=0.181 n=6+8) Unmapped-6 414ns ± 5% 402ns ±10% ~ (p=0.244 n=7+8) Unmapped-48 226ns ± 2% 224ns ± 2% ~ (p=0.144 n=7+8) NumberIsValid 20.1ns ± 4% 19.7ns ± 3% ~ (p=0.204 n=8+8) NumberIsValid-6 20.4ns ± 8% 22.2ns ±16% ~ (p=0.129 n=7+8) NumberIsValid-48 23.1ns ±12% 23.8ns ± 8% ~ (p=0.104 n=8+8) NumberIsValidRegexp 629ns ± 5% 622ns ± 0% ~ (p=0.148 n=7+7) NumberIsValidRegexp-6 757ns ± 2% 725ns ±14% ~ (p=0.351 n=8+7) NumberIsValidRegexp-48 757ns ± 2% 723ns ±13% ~ (p=0.521 n=8+8) SkipValue 13.2ms ± 9% 13.3ms ± 1% ~ (p=0.130 n=8+8) SkipValue-6 15.1ms ±10% 14.8ms ± 2% ~ (p=0.397 n=7+8) SkipValue-48 13.9ms ±12% 14.3ms ± 1% ~ (p=0.694 n=8+7) EncoderEncode 433ns ± 4% 410ns ± 3% -5.48% (p=0.001 n=8+8) EncoderEncode-6 221ns ±15% 75ns ± 5% -66.15% (p=0.000 n=7+8) EncoderEncode-48 161ns ± 4% 19ns ± 7% -88.29% (p=0.000 n=7+8) name old speed new speed delta CodeEncoder 139MB/s ±10% 144MB/s ± 4% ~ (p=0.844 n=8+7) CodeEncoder-6 756MB/s ± 8% 714MB/s ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 3.08GB/s ± 1% 3.09GB/s ± 1% ~ (p=0.867 n=8+7) CodeMarshal 130MB/s ± 5% 130MB/s ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 594MB/s ±10% 601MB/s ±11% ~ (p=0.798 n=8+8) CodeMarshal-48 2.62GB/s ± 1% 2.60GB/s ± 2% ~ (p=0.328 n=8+8) CodeDecoder 39.0MB/s ± 4% 39.5MB/s ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 189MB/s ±13% 187MB/s ± 3% ~ (p=0.505 n=8+8) CodeDecoder-48 746MB/s ± 2% 745MB/s ± 2% ~ (p=1.000 n=8+8) CodeUnmarshal 37.2MB/s ± 5% 35.9MB/s ±16% ~ (p=0.955 n=7+8) CodeUnmarshal-6 157MB/s ± 6% 158MB/s ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 561MB/s ± 7% 572MB/s ±10% ~ (p=0.442 n=8+8) SkipValue 141MB/s ±10% 139MB/s ± 1% ~ (p=0.130 n=8+8) SkipValue-6 131MB/s ± 3% 133MB/s ± 2% ~ (p=0.662 n=6+8) SkipValue-48 138MB/s ±11% 132MB/s ± 1% ~ (p=0.281 n=8+7) name old alloc/op new alloc/op delta CodeEncoder 45.9kB ± 0% 45.9kB ± 0% -0.02% (p=0.002 n=7+8) CodeEncoder-6 55.1kB ± 0% 55.1kB ± 0% -0.01% (p=0.002 n=7+8) CodeEncoder-48 110kB ± 0% 110kB ± 0% -0.00% (p=0.030 n=7+8) CodeMarshal 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-6 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-48 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.001 n=7+8) CodeDecoder 2.28MB ± 5% 2.21MB ± 0% ~ (p=0.257 n=8+7) CodeDecoder-6 2.43MB ±11% 2.51MB ± 0% ~ (p=0.473 n=8+8) CodeDecoder-48 2.93MB ± 0% 2.93MB ± 0% ~ (p=0.554 n=7+8) DecoderStream 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-6 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-48 16.0B ± 0% 16.0B ± 0% ~ (all equal) CodeUnmarshal 3.28MB ± 0% 3.28MB ± 0% ~ (p=1.000 n=7+7) CodeUnmarshal-6 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.593 n=8+8) CodeUnmarshal-48 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.670 n=8+8) CodeUnmarshalReuse 1.87MB ± 0% 1.88MB ± 1% +0.48% (p=0.011 n=7+8) CodeUnmarshalReuse-6 1.90MB ± 1% 1.90MB ± 1% ~ (p=0.589 n=8+8) CodeUnmarshalReuse-48 1.96MB ± 0% 1.96MB ± 0% +0.00% (p=0.002 n=7+8) UnmarshalString 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-6 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-48 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalFloat64 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-6 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-48 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalInt64 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-6 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-48 289B ± 0% 289B ± 0% ~ (all equal) Issue10335 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-6 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-48 312B ± 0% 312B ± 0% ~ (all equal) Unmapped 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-6 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-48 344B ± 0% 344B ± 0% ~ (all equal) NumberIsValid 0.00B 0.00B ~ (all equal) NumberIsValid-6 0.00B 0.00B ~ (all equal) NumberIsValid-48 0.00B 0.00B ~ (all equal) NumberIsValidRegexp 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-6 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-48 0.00B 0.00B ~ (all equal) SkipValue 0.00B 0.00B ~ (all equal) SkipValue-6 0.00B 0.00B ~ (all equal) SkipValue-48 15.0B ±167% 0.0B ~ (p=0.200 n=8+8) EncoderEncode 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-6 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-48 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) name old allocs/op new allocs/op delta CodeEncoder 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeMarshal 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-6 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-48 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeDecoder 89.6k ± 0% 89.5k ± 0% ~ (p=0.154 n=8+7) CodeDecoder-6 89.8k ± 0% 89.9k ± 0% ~ (p=0.467 n=8+8) CodeDecoder-48 90.5k ± 0% 90.5k ± 0% ~ (p=0.533 n=8+7) DecoderStream 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) CodeUnmarshal 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-6 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-48 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshalReuse 89.5k ± 0% 89.6k ± 0% ~ (p=0.246 n=7+8) CodeUnmarshalReuse-6 89.8k ± 0% 89.8k ± 0% ~ (p=1.000 n=8+8) CodeUnmarshalReuse-48 90.5k ± 0% 90.5k ± 0% ~ (all equal) UnmarshalString 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) Issue10335 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-6 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-48 3.00 ± 0% 3.00 ± 0% ~ (all equal) Unmapped 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-6 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-48 4.00 ± 0% 4.00 ± 0% ~ (all equal) NumberIsValid 0.00 0.00 ~ (all equal) NumberIsValid-6 0.00 0.00 ~ (all equal) NumberIsValid-48 0.00 0.00 ~ (all equal) NumberIsValidRegexp 0.00 0.00 ~ (all equal) NumberIsValidRegexp-6 0.00 0.00 ~ (all equal) NumberIsValidRegexp-48 0.00 0.00 ~ (all equal) SkipValue 0.00 0.00 ~ (all equal) SkipValue-6 0.00 0.00 ~ (all equal) SkipValue-48 0.00 0.00 ~ (all equal) EncoderEncode 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) https://perf.golang.org/search?q=upload:20170427.2 updates #17973 updates #18177 Change-Id: I5881c7a2bfad1766e6aa3444bb630883e0be467b Reviewed-on: https://go-review.googlesource.com/41931 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-02-16 17:41:13 -05:00
fi, loaded := encoderCache.LoadOrStore(t, encoderFunc(func(e *encodeState, v reflect.Value, opts encOpts) {
wg.Wait()
f(e, v, opts)
encoding/json: replace encoderCache RWMutex with a sync.Map This provides a moderate speedup for encoding when using many CPU cores. name old time/op new time/op delta CodeEncoder 14.1ms ±10% 13.5ms ± 4% ~ (p=0.867 n=8+7) CodeEncoder-6 2.58ms ± 8% 2.72ms ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 629µs ± 1% 629µs ± 1% ~ (p=0.867 n=8+7) CodeMarshal 14.9ms ± 5% 14.9ms ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 3.28ms ±11% 3.24ms ±12% ~ (p=0.798 n=8+8) CodeMarshal-48 739µs ± 1% 745µs ± 2% ~ (p=0.328 n=8+8) CodeDecoder 49.7ms ± 4% 49.2ms ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 10.1ms ± 8% 10.4ms ± 3% ~ (p=0.232 n=7+8) CodeDecoder-48 2.60ms ± 3% 2.61ms ± 2% ~ (p=1.000 n=8+8) DecoderStream 352ns ± 5% 344ns ± 4% ~ (p=0.077 n=8+8) DecoderStream-6 485ns ± 8% 503ns ± 6% ~ (p=0.123 n=8+8) DecoderStream-48 522ns ± 7% 520ns ± 5% ~ (p=0.959 n=8+8) CodeUnmarshal 52.2ms ± 5% 54.4ms ±18% ~ (p=0.955 n=7+8) CodeUnmarshal-6 12.4ms ± 6% 12.3ms ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 3.46ms ± 7% 3.40ms ± 9% ~ (p=0.442 n=8+8) CodeUnmarshalReuse 48.9ms ± 6% 50.3ms ± 7% ~ (p=0.279 n=8+8) CodeUnmarshalReuse-6 10.3ms ±11% 10.3ms ±10% ~ (p=0.959 n=8+8) CodeUnmarshalReuse-48 2.68ms ± 3% 2.67ms ± 4% ~ (p=0.878 n=8+8) UnmarshalString 476ns ± 7% 474ns ± 7% ~ (p=0.644 n=8+8) UnmarshalString-6 164ns ± 9% 160ns ±10% ~ (p=0.556 n=8+8) UnmarshalString-48 181ns ± 0% 177ns ± 2% -2.36% (p=0.001 n=7+7) UnmarshalFloat64 414ns ± 4% 418ns ± 4% ~ (p=0.382 n=8+8) UnmarshalFloat64-6 147ns ± 9% 143ns ±16% ~ (p=0.457 n=8+8) UnmarshalFloat64-48 176ns ± 2% 174ns ± 2% ~ (p=0.118 n=8+8) UnmarshalInt64 369ns ± 4% 354ns ± 1% -3.85% (p=0.005 n=8+7) UnmarshalInt64-6 132ns ±11% 132ns ±10% ~ (p=0.982 n=8+8) UnmarshalInt64-48 177ns ± 3% 174ns ± 2% -1.84% (p=0.028 n=8+7) Issue10335 540ns ± 5% 535ns ± 0% ~ (p=0.330 n=7+7) Issue10335-6 159ns ± 8% 164ns ± 8% ~ (p=0.246 n=8+8) Issue10335-48 186ns ± 1% 182ns ± 2% -1.89% (p=0.010 n=8+8) Unmapped 1.74µs ± 2% 1.76µs ± 6% ~ (p=0.181 n=6+8) Unmapped-6 414ns ± 5% 402ns ±10% ~ (p=0.244 n=7+8) Unmapped-48 226ns ± 2% 224ns ± 2% ~ (p=0.144 n=7+8) NumberIsValid 20.1ns ± 4% 19.7ns ± 3% ~ (p=0.204 n=8+8) NumberIsValid-6 20.4ns ± 8% 22.2ns ±16% ~ (p=0.129 n=7+8) NumberIsValid-48 23.1ns ±12% 23.8ns ± 8% ~ (p=0.104 n=8+8) NumberIsValidRegexp 629ns ± 5% 622ns ± 0% ~ (p=0.148 n=7+7) NumberIsValidRegexp-6 757ns ± 2% 725ns ±14% ~ (p=0.351 n=8+7) NumberIsValidRegexp-48 757ns ± 2% 723ns ±13% ~ (p=0.521 n=8+8) SkipValue 13.2ms ± 9% 13.3ms ± 1% ~ (p=0.130 n=8+8) SkipValue-6 15.1ms ±10% 14.8ms ± 2% ~ (p=0.397 n=7+8) SkipValue-48 13.9ms ±12% 14.3ms ± 1% ~ (p=0.694 n=8+7) EncoderEncode 433ns ± 4% 410ns ± 3% -5.48% (p=0.001 n=8+8) EncoderEncode-6 221ns ±15% 75ns ± 5% -66.15% (p=0.000 n=7+8) EncoderEncode-48 161ns ± 4% 19ns ± 7% -88.29% (p=0.000 n=7+8) name old speed new speed delta CodeEncoder 139MB/s ±10% 144MB/s ± 4% ~ (p=0.844 n=8+7) CodeEncoder-6 756MB/s ± 8% 714MB/s ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 3.08GB/s ± 1% 3.09GB/s ± 1% ~ (p=0.867 n=8+7) CodeMarshal 130MB/s ± 5% 130MB/s ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 594MB/s ±10% 601MB/s ±11% ~ (p=0.798 n=8+8) CodeMarshal-48 2.62GB/s ± 1% 2.60GB/s ± 2% ~ (p=0.328 n=8+8) CodeDecoder 39.0MB/s ± 4% 39.5MB/s ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 189MB/s ±13% 187MB/s ± 3% ~ (p=0.505 n=8+8) CodeDecoder-48 746MB/s ± 2% 745MB/s ± 2% ~ (p=1.000 n=8+8) CodeUnmarshal 37.2MB/s ± 5% 35.9MB/s ±16% ~ (p=0.955 n=7+8) CodeUnmarshal-6 157MB/s ± 6% 158MB/s ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 561MB/s ± 7% 572MB/s ±10% ~ (p=0.442 n=8+8) SkipValue 141MB/s ±10% 139MB/s ± 1% ~ (p=0.130 n=8+8) SkipValue-6 131MB/s ± 3% 133MB/s ± 2% ~ (p=0.662 n=6+8) SkipValue-48 138MB/s ±11% 132MB/s ± 1% ~ (p=0.281 n=8+7) name old alloc/op new alloc/op delta CodeEncoder 45.9kB ± 0% 45.9kB ± 0% -0.02% (p=0.002 n=7+8) CodeEncoder-6 55.1kB ± 0% 55.1kB ± 0% -0.01% (p=0.002 n=7+8) CodeEncoder-48 110kB ± 0% 110kB ± 0% -0.00% (p=0.030 n=7+8) CodeMarshal 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-6 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-48 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.001 n=7+8) CodeDecoder 2.28MB ± 5% 2.21MB ± 0% ~ (p=0.257 n=8+7) CodeDecoder-6 2.43MB ±11% 2.51MB ± 0% ~ (p=0.473 n=8+8) CodeDecoder-48 2.93MB ± 0% 2.93MB ± 0% ~ (p=0.554 n=7+8) DecoderStream 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-6 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-48 16.0B ± 0% 16.0B ± 0% ~ (all equal) CodeUnmarshal 3.28MB ± 0% 3.28MB ± 0% ~ (p=1.000 n=7+7) CodeUnmarshal-6 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.593 n=8+8) CodeUnmarshal-48 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.670 n=8+8) CodeUnmarshalReuse 1.87MB ± 0% 1.88MB ± 1% +0.48% (p=0.011 n=7+8) CodeUnmarshalReuse-6 1.90MB ± 1% 1.90MB ± 1% ~ (p=0.589 n=8+8) CodeUnmarshalReuse-48 1.96MB ± 0% 1.96MB ± 0% +0.00% (p=0.002 n=7+8) UnmarshalString 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-6 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-48 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalFloat64 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-6 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-48 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalInt64 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-6 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-48 289B ± 0% 289B ± 0% ~ (all equal) Issue10335 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-6 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-48 312B ± 0% 312B ± 0% ~ (all equal) Unmapped 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-6 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-48 344B ± 0% 344B ± 0% ~ (all equal) NumberIsValid 0.00B 0.00B ~ (all equal) NumberIsValid-6 0.00B 0.00B ~ (all equal) NumberIsValid-48 0.00B 0.00B ~ (all equal) NumberIsValidRegexp 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-6 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-48 0.00B 0.00B ~ (all equal) SkipValue 0.00B 0.00B ~ (all equal) SkipValue-6 0.00B 0.00B ~ (all equal) SkipValue-48 15.0B ±167% 0.0B ~ (p=0.200 n=8+8) EncoderEncode 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-6 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-48 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) name old allocs/op new allocs/op delta CodeEncoder 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeMarshal 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-6 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-48 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeDecoder 89.6k ± 0% 89.5k ± 0% ~ (p=0.154 n=8+7) CodeDecoder-6 89.8k ± 0% 89.9k ± 0% ~ (p=0.467 n=8+8) CodeDecoder-48 90.5k ± 0% 90.5k ± 0% ~ (p=0.533 n=8+7) DecoderStream 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) CodeUnmarshal 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-6 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-48 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshalReuse 89.5k ± 0% 89.6k ± 0% ~ (p=0.246 n=7+8) CodeUnmarshalReuse-6 89.8k ± 0% 89.8k ± 0% ~ (p=1.000 n=8+8) CodeUnmarshalReuse-48 90.5k ± 0% 90.5k ± 0% ~ (all equal) UnmarshalString 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) Issue10335 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-6 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-48 3.00 ± 0% 3.00 ± 0% ~ (all equal) Unmapped 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-6 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-48 4.00 ± 0% 4.00 ± 0% ~ (all equal) NumberIsValid 0.00 0.00 ~ (all equal) NumberIsValid-6 0.00 0.00 ~ (all equal) NumberIsValid-48 0.00 0.00 ~ (all equal) NumberIsValidRegexp 0.00 0.00 ~ (all equal) NumberIsValidRegexp-6 0.00 0.00 ~ (all equal) NumberIsValidRegexp-48 0.00 0.00 ~ (all equal) SkipValue 0.00 0.00 ~ (all equal) SkipValue-6 0.00 0.00 ~ (all equal) SkipValue-48 0.00 0.00 ~ (all equal) EncoderEncode 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) https://perf.golang.org/search?q=upload:20170427.2 updates #17973 updates #18177 Change-Id: I5881c7a2bfad1766e6aa3444bb630883e0be467b Reviewed-on: https://go-review.googlesource.com/41931 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-02-16 17:41:13 -05:00
}))
if loaded {
return fi.(encoderFunc)
}
encoding/json: replace encoderCache RWMutex with a sync.Map This provides a moderate speedup for encoding when using many CPU cores. name old time/op new time/op delta CodeEncoder 14.1ms ±10% 13.5ms ± 4% ~ (p=0.867 n=8+7) CodeEncoder-6 2.58ms ± 8% 2.72ms ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 629µs ± 1% 629µs ± 1% ~ (p=0.867 n=8+7) CodeMarshal 14.9ms ± 5% 14.9ms ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 3.28ms ±11% 3.24ms ±12% ~ (p=0.798 n=8+8) CodeMarshal-48 739µs ± 1% 745µs ± 2% ~ (p=0.328 n=8+8) CodeDecoder 49.7ms ± 4% 49.2ms ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 10.1ms ± 8% 10.4ms ± 3% ~ (p=0.232 n=7+8) CodeDecoder-48 2.60ms ± 3% 2.61ms ± 2% ~ (p=1.000 n=8+8) DecoderStream 352ns ± 5% 344ns ± 4% ~ (p=0.077 n=8+8) DecoderStream-6 485ns ± 8% 503ns ± 6% ~ (p=0.123 n=8+8) DecoderStream-48 522ns ± 7% 520ns ± 5% ~ (p=0.959 n=8+8) CodeUnmarshal 52.2ms ± 5% 54.4ms ±18% ~ (p=0.955 n=7+8) CodeUnmarshal-6 12.4ms ± 6% 12.3ms ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 3.46ms ± 7% 3.40ms ± 9% ~ (p=0.442 n=8+8) CodeUnmarshalReuse 48.9ms ± 6% 50.3ms ± 7% ~ (p=0.279 n=8+8) CodeUnmarshalReuse-6 10.3ms ±11% 10.3ms ±10% ~ (p=0.959 n=8+8) CodeUnmarshalReuse-48 2.68ms ± 3% 2.67ms ± 4% ~ (p=0.878 n=8+8) UnmarshalString 476ns ± 7% 474ns ± 7% ~ (p=0.644 n=8+8) UnmarshalString-6 164ns ± 9% 160ns ±10% ~ (p=0.556 n=8+8) UnmarshalString-48 181ns ± 0% 177ns ± 2% -2.36% (p=0.001 n=7+7) UnmarshalFloat64 414ns ± 4% 418ns ± 4% ~ (p=0.382 n=8+8) UnmarshalFloat64-6 147ns ± 9% 143ns ±16% ~ (p=0.457 n=8+8) UnmarshalFloat64-48 176ns ± 2% 174ns ± 2% ~ (p=0.118 n=8+8) UnmarshalInt64 369ns ± 4% 354ns ± 1% -3.85% (p=0.005 n=8+7) UnmarshalInt64-6 132ns ±11% 132ns ±10% ~ (p=0.982 n=8+8) UnmarshalInt64-48 177ns ± 3% 174ns ± 2% -1.84% (p=0.028 n=8+7) Issue10335 540ns ± 5% 535ns ± 0% ~ (p=0.330 n=7+7) Issue10335-6 159ns ± 8% 164ns ± 8% ~ (p=0.246 n=8+8) Issue10335-48 186ns ± 1% 182ns ± 2% -1.89% (p=0.010 n=8+8) Unmapped 1.74µs ± 2% 1.76µs ± 6% ~ (p=0.181 n=6+8) Unmapped-6 414ns ± 5% 402ns ±10% ~ (p=0.244 n=7+8) Unmapped-48 226ns ± 2% 224ns ± 2% ~ (p=0.144 n=7+8) NumberIsValid 20.1ns ± 4% 19.7ns ± 3% ~ (p=0.204 n=8+8) NumberIsValid-6 20.4ns ± 8% 22.2ns ±16% ~ (p=0.129 n=7+8) NumberIsValid-48 23.1ns ±12% 23.8ns ± 8% ~ (p=0.104 n=8+8) NumberIsValidRegexp 629ns ± 5% 622ns ± 0% ~ (p=0.148 n=7+7) NumberIsValidRegexp-6 757ns ± 2% 725ns ±14% ~ (p=0.351 n=8+7) NumberIsValidRegexp-48 757ns ± 2% 723ns ±13% ~ (p=0.521 n=8+8) SkipValue 13.2ms ± 9% 13.3ms ± 1% ~ (p=0.130 n=8+8) SkipValue-6 15.1ms ±10% 14.8ms ± 2% ~ (p=0.397 n=7+8) SkipValue-48 13.9ms ±12% 14.3ms ± 1% ~ (p=0.694 n=8+7) EncoderEncode 433ns ± 4% 410ns ± 3% -5.48% (p=0.001 n=8+8) EncoderEncode-6 221ns ±15% 75ns ± 5% -66.15% (p=0.000 n=7+8) EncoderEncode-48 161ns ± 4% 19ns ± 7% -88.29% (p=0.000 n=7+8) name old speed new speed delta CodeEncoder 139MB/s ±10% 144MB/s ± 4% ~ (p=0.844 n=8+7) CodeEncoder-6 756MB/s ± 8% 714MB/s ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 3.08GB/s ± 1% 3.09GB/s ± 1% ~ (p=0.867 n=8+7) CodeMarshal 130MB/s ± 5% 130MB/s ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 594MB/s ±10% 601MB/s ±11% ~ (p=0.798 n=8+8) CodeMarshal-48 2.62GB/s ± 1% 2.60GB/s ± 2% ~ (p=0.328 n=8+8) CodeDecoder 39.0MB/s ± 4% 39.5MB/s ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 189MB/s ±13% 187MB/s ± 3% ~ (p=0.505 n=8+8) CodeDecoder-48 746MB/s ± 2% 745MB/s ± 2% ~ (p=1.000 n=8+8) CodeUnmarshal 37.2MB/s ± 5% 35.9MB/s ±16% ~ (p=0.955 n=7+8) CodeUnmarshal-6 157MB/s ± 6% 158MB/s ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 561MB/s ± 7% 572MB/s ±10% ~ (p=0.442 n=8+8) SkipValue 141MB/s ±10% 139MB/s ± 1% ~ (p=0.130 n=8+8) SkipValue-6 131MB/s ± 3% 133MB/s ± 2% ~ (p=0.662 n=6+8) SkipValue-48 138MB/s ±11% 132MB/s ± 1% ~ (p=0.281 n=8+7) name old alloc/op new alloc/op delta CodeEncoder 45.9kB ± 0% 45.9kB ± 0% -0.02% (p=0.002 n=7+8) CodeEncoder-6 55.1kB ± 0% 55.1kB ± 0% -0.01% (p=0.002 n=7+8) CodeEncoder-48 110kB ± 0% 110kB ± 0% -0.00% (p=0.030 n=7+8) CodeMarshal 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-6 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-48 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.001 n=7+8) CodeDecoder 2.28MB ± 5% 2.21MB ± 0% ~ (p=0.257 n=8+7) CodeDecoder-6 2.43MB ±11% 2.51MB ± 0% ~ (p=0.473 n=8+8) CodeDecoder-48 2.93MB ± 0% 2.93MB ± 0% ~ (p=0.554 n=7+8) DecoderStream 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-6 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-48 16.0B ± 0% 16.0B ± 0% ~ (all equal) CodeUnmarshal 3.28MB ± 0% 3.28MB ± 0% ~ (p=1.000 n=7+7) CodeUnmarshal-6 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.593 n=8+8) CodeUnmarshal-48 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.670 n=8+8) CodeUnmarshalReuse 1.87MB ± 0% 1.88MB ± 1% +0.48% (p=0.011 n=7+8) CodeUnmarshalReuse-6 1.90MB ± 1% 1.90MB ± 1% ~ (p=0.589 n=8+8) CodeUnmarshalReuse-48 1.96MB ± 0% 1.96MB ± 0% +0.00% (p=0.002 n=7+8) UnmarshalString 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-6 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-48 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalFloat64 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-6 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-48 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalInt64 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-6 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-48 289B ± 0% 289B ± 0% ~ (all equal) Issue10335 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-6 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-48 312B ± 0% 312B ± 0% ~ (all equal) Unmapped 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-6 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-48 344B ± 0% 344B ± 0% ~ (all equal) NumberIsValid 0.00B 0.00B ~ (all equal) NumberIsValid-6 0.00B 0.00B ~ (all equal) NumberIsValid-48 0.00B 0.00B ~ (all equal) NumberIsValidRegexp 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-6 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-48 0.00B 0.00B ~ (all equal) SkipValue 0.00B 0.00B ~ (all equal) SkipValue-6 0.00B 0.00B ~ (all equal) SkipValue-48 15.0B ±167% 0.0B ~ (p=0.200 n=8+8) EncoderEncode 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-6 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-48 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) name old allocs/op new allocs/op delta CodeEncoder 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeMarshal 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-6 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-48 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeDecoder 89.6k ± 0% 89.5k ± 0% ~ (p=0.154 n=8+7) CodeDecoder-6 89.8k ± 0% 89.9k ± 0% ~ (p=0.467 n=8+8) CodeDecoder-48 90.5k ± 0% 90.5k ± 0% ~ (p=0.533 n=8+7) DecoderStream 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) CodeUnmarshal 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-6 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-48 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshalReuse 89.5k ± 0% 89.6k ± 0% ~ (p=0.246 n=7+8) CodeUnmarshalReuse-6 89.8k ± 0% 89.8k ± 0% ~ (p=1.000 n=8+8) CodeUnmarshalReuse-48 90.5k ± 0% 90.5k ± 0% ~ (all equal) UnmarshalString 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) Issue10335 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-6 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-48 3.00 ± 0% 3.00 ± 0% ~ (all equal) Unmapped 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-6 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-48 4.00 ± 0% 4.00 ± 0% ~ (all equal) NumberIsValid 0.00 0.00 ~ (all equal) NumberIsValid-6 0.00 0.00 ~ (all equal) NumberIsValid-48 0.00 0.00 ~ (all equal) NumberIsValidRegexp 0.00 0.00 ~ (all equal) NumberIsValidRegexp-6 0.00 0.00 ~ (all equal) NumberIsValidRegexp-48 0.00 0.00 ~ (all equal) SkipValue 0.00 0.00 ~ (all equal) SkipValue-6 0.00 0.00 ~ (all equal) SkipValue-48 0.00 0.00 ~ (all equal) EncoderEncode 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) https://perf.golang.org/search?q=upload:20170427.2 updates #17973 updates #18177 Change-Id: I5881c7a2bfad1766e6aa3444bb630883e0be467b Reviewed-on: https://go-review.googlesource.com/41931 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-02-16 17:41:13 -05:00
// Compute the real encoder and replace the indirect func with it.
f = newTypeEncoder(t, true)
wg.Done()
encoding/json: replace encoderCache RWMutex with a sync.Map This provides a moderate speedup for encoding when using many CPU cores. name old time/op new time/op delta CodeEncoder 14.1ms ±10% 13.5ms ± 4% ~ (p=0.867 n=8+7) CodeEncoder-6 2.58ms ± 8% 2.72ms ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 629µs ± 1% 629µs ± 1% ~ (p=0.867 n=8+7) CodeMarshal 14.9ms ± 5% 14.9ms ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 3.28ms ±11% 3.24ms ±12% ~ (p=0.798 n=8+8) CodeMarshal-48 739µs ± 1% 745µs ± 2% ~ (p=0.328 n=8+8) CodeDecoder 49.7ms ± 4% 49.2ms ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 10.1ms ± 8% 10.4ms ± 3% ~ (p=0.232 n=7+8) CodeDecoder-48 2.60ms ± 3% 2.61ms ± 2% ~ (p=1.000 n=8+8) DecoderStream 352ns ± 5% 344ns ± 4% ~ (p=0.077 n=8+8) DecoderStream-6 485ns ± 8% 503ns ± 6% ~ (p=0.123 n=8+8) DecoderStream-48 522ns ± 7% 520ns ± 5% ~ (p=0.959 n=8+8) CodeUnmarshal 52.2ms ± 5% 54.4ms ±18% ~ (p=0.955 n=7+8) CodeUnmarshal-6 12.4ms ± 6% 12.3ms ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 3.46ms ± 7% 3.40ms ± 9% ~ (p=0.442 n=8+8) CodeUnmarshalReuse 48.9ms ± 6% 50.3ms ± 7% ~ (p=0.279 n=8+8) CodeUnmarshalReuse-6 10.3ms ±11% 10.3ms ±10% ~ (p=0.959 n=8+8) CodeUnmarshalReuse-48 2.68ms ± 3% 2.67ms ± 4% ~ (p=0.878 n=8+8) UnmarshalString 476ns ± 7% 474ns ± 7% ~ (p=0.644 n=8+8) UnmarshalString-6 164ns ± 9% 160ns ±10% ~ (p=0.556 n=8+8) UnmarshalString-48 181ns ± 0% 177ns ± 2% -2.36% (p=0.001 n=7+7) UnmarshalFloat64 414ns ± 4% 418ns ± 4% ~ (p=0.382 n=8+8) UnmarshalFloat64-6 147ns ± 9% 143ns ±16% ~ (p=0.457 n=8+8) UnmarshalFloat64-48 176ns ± 2% 174ns ± 2% ~ (p=0.118 n=8+8) UnmarshalInt64 369ns ± 4% 354ns ± 1% -3.85% (p=0.005 n=8+7) UnmarshalInt64-6 132ns ±11% 132ns ±10% ~ (p=0.982 n=8+8) UnmarshalInt64-48 177ns ± 3% 174ns ± 2% -1.84% (p=0.028 n=8+7) Issue10335 540ns ± 5% 535ns ± 0% ~ (p=0.330 n=7+7) Issue10335-6 159ns ± 8% 164ns ± 8% ~ (p=0.246 n=8+8) Issue10335-48 186ns ± 1% 182ns ± 2% -1.89% (p=0.010 n=8+8) Unmapped 1.74µs ± 2% 1.76µs ± 6% ~ (p=0.181 n=6+8) Unmapped-6 414ns ± 5% 402ns ±10% ~ (p=0.244 n=7+8) Unmapped-48 226ns ± 2% 224ns ± 2% ~ (p=0.144 n=7+8) NumberIsValid 20.1ns ± 4% 19.7ns ± 3% ~ (p=0.204 n=8+8) NumberIsValid-6 20.4ns ± 8% 22.2ns ±16% ~ (p=0.129 n=7+8) NumberIsValid-48 23.1ns ±12% 23.8ns ± 8% ~ (p=0.104 n=8+8) NumberIsValidRegexp 629ns ± 5% 622ns ± 0% ~ (p=0.148 n=7+7) NumberIsValidRegexp-6 757ns ± 2% 725ns ±14% ~ (p=0.351 n=8+7) NumberIsValidRegexp-48 757ns ± 2% 723ns ±13% ~ (p=0.521 n=8+8) SkipValue 13.2ms ± 9% 13.3ms ± 1% ~ (p=0.130 n=8+8) SkipValue-6 15.1ms ±10% 14.8ms ± 2% ~ (p=0.397 n=7+8) SkipValue-48 13.9ms ±12% 14.3ms ± 1% ~ (p=0.694 n=8+7) EncoderEncode 433ns ± 4% 410ns ± 3% -5.48% (p=0.001 n=8+8) EncoderEncode-6 221ns ±15% 75ns ± 5% -66.15% (p=0.000 n=7+8) EncoderEncode-48 161ns ± 4% 19ns ± 7% -88.29% (p=0.000 n=7+8) name old speed new speed delta CodeEncoder 139MB/s ±10% 144MB/s ± 4% ~ (p=0.844 n=8+7) CodeEncoder-6 756MB/s ± 8% 714MB/s ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 3.08GB/s ± 1% 3.09GB/s ± 1% ~ (p=0.867 n=8+7) CodeMarshal 130MB/s ± 5% 130MB/s ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 594MB/s ±10% 601MB/s ±11% ~ (p=0.798 n=8+8) CodeMarshal-48 2.62GB/s ± 1% 2.60GB/s ± 2% ~ (p=0.328 n=8+8) CodeDecoder 39.0MB/s ± 4% 39.5MB/s ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 189MB/s ±13% 187MB/s ± 3% ~ (p=0.505 n=8+8) CodeDecoder-48 746MB/s ± 2% 745MB/s ± 2% ~ (p=1.000 n=8+8) CodeUnmarshal 37.2MB/s ± 5% 35.9MB/s ±16% ~ (p=0.955 n=7+8) CodeUnmarshal-6 157MB/s ± 6% 158MB/s ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 561MB/s ± 7% 572MB/s ±10% ~ (p=0.442 n=8+8) SkipValue 141MB/s ±10% 139MB/s ± 1% ~ (p=0.130 n=8+8) SkipValue-6 131MB/s ± 3% 133MB/s ± 2% ~ (p=0.662 n=6+8) SkipValue-48 138MB/s ±11% 132MB/s ± 1% ~ (p=0.281 n=8+7) name old alloc/op new alloc/op delta CodeEncoder 45.9kB ± 0% 45.9kB ± 0% -0.02% (p=0.002 n=7+8) CodeEncoder-6 55.1kB ± 0% 55.1kB ± 0% -0.01% (p=0.002 n=7+8) CodeEncoder-48 110kB ± 0% 110kB ± 0% -0.00% (p=0.030 n=7+8) CodeMarshal 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-6 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-48 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.001 n=7+8) CodeDecoder 2.28MB ± 5% 2.21MB ± 0% ~ (p=0.257 n=8+7) CodeDecoder-6 2.43MB ±11% 2.51MB ± 0% ~ (p=0.473 n=8+8) CodeDecoder-48 2.93MB ± 0% 2.93MB ± 0% ~ (p=0.554 n=7+8) DecoderStream 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-6 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-48 16.0B ± 0% 16.0B ± 0% ~ (all equal) CodeUnmarshal 3.28MB ± 0% 3.28MB ± 0% ~ (p=1.000 n=7+7) CodeUnmarshal-6 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.593 n=8+8) CodeUnmarshal-48 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.670 n=8+8) CodeUnmarshalReuse 1.87MB ± 0% 1.88MB ± 1% +0.48% (p=0.011 n=7+8) CodeUnmarshalReuse-6 1.90MB ± 1% 1.90MB ± 1% ~ (p=0.589 n=8+8) CodeUnmarshalReuse-48 1.96MB ± 0% 1.96MB ± 0% +0.00% (p=0.002 n=7+8) UnmarshalString 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-6 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-48 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalFloat64 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-6 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-48 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalInt64 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-6 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-48 289B ± 0% 289B ± 0% ~ (all equal) Issue10335 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-6 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-48 312B ± 0% 312B ± 0% ~ (all equal) Unmapped 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-6 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-48 344B ± 0% 344B ± 0% ~ (all equal) NumberIsValid 0.00B 0.00B ~ (all equal) NumberIsValid-6 0.00B 0.00B ~ (all equal) NumberIsValid-48 0.00B 0.00B ~ (all equal) NumberIsValidRegexp 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-6 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-48 0.00B 0.00B ~ (all equal) SkipValue 0.00B 0.00B ~ (all equal) SkipValue-6 0.00B 0.00B ~ (all equal) SkipValue-48 15.0B ±167% 0.0B ~ (p=0.200 n=8+8) EncoderEncode 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-6 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-48 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) name old allocs/op new allocs/op delta CodeEncoder 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeMarshal 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-6 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-48 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeDecoder 89.6k ± 0% 89.5k ± 0% ~ (p=0.154 n=8+7) CodeDecoder-6 89.8k ± 0% 89.9k ± 0% ~ (p=0.467 n=8+8) CodeDecoder-48 90.5k ± 0% 90.5k ± 0% ~ (p=0.533 n=8+7) DecoderStream 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) CodeUnmarshal 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-6 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-48 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshalReuse 89.5k ± 0% 89.6k ± 0% ~ (p=0.246 n=7+8) CodeUnmarshalReuse-6 89.8k ± 0% 89.8k ± 0% ~ (p=1.000 n=8+8) CodeUnmarshalReuse-48 90.5k ± 0% 90.5k ± 0% ~ (all equal) UnmarshalString 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) Issue10335 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-6 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-48 3.00 ± 0% 3.00 ± 0% ~ (all equal) Unmapped 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-6 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-48 4.00 ± 0% 4.00 ± 0% ~ (all equal) NumberIsValid 0.00 0.00 ~ (all equal) NumberIsValid-6 0.00 0.00 ~ (all equal) NumberIsValid-48 0.00 0.00 ~ (all equal) NumberIsValidRegexp 0.00 0.00 ~ (all equal) NumberIsValidRegexp-6 0.00 0.00 ~ (all equal) NumberIsValidRegexp-48 0.00 0.00 ~ (all equal) SkipValue 0.00 0.00 ~ (all equal) SkipValue-6 0.00 0.00 ~ (all equal) SkipValue-48 0.00 0.00 ~ (all equal) EncoderEncode 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) https://perf.golang.org/search?q=upload:20170427.2 updates #17973 updates #18177 Change-Id: I5881c7a2bfad1766e6aa3444bb630883e0be467b Reviewed-on: https://go-review.googlesource.com/41931 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-02-16 17:41:13 -05:00
encoderCache.Store(t, f)
return f
}
var (
marshalerType = reflect.TypeOf((*Marshaler)(nil)).Elem()
textMarshalerType = reflect.TypeOf((*encoding.TextMarshaler)(nil)).Elem()
)
// newTypeEncoder constructs an encoderFunc for a type.
// The returned encoder only checks CanAddr when allowAddr is true.
func newTypeEncoder(t reflect.Type, allowAddr bool) encoderFunc {
// If we have a non-pointer value whose type implements
// Marshaler with a value receiver, then we're better off taking
// the address of the value - otherwise we end up with an
// allocation as we cast the value to an interface.
if t.Kind() != reflect.Pointer && allowAddr && reflect.PointerTo(t).Implements(marshalerType) {
return newCondAddrEncoder(addrMarshalerEncoder, newTypeEncoder(t, false))
}
if t.Implements(marshalerType) {
return marshalerEncoder
}
if t.Kind() != reflect.Pointer && allowAddr && reflect.PointerTo(t).Implements(textMarshalerType) {
return newCondAddrEncoder(addrTextMarshalerEncoder, newTypeEncoder(t, false))
}
if t.Implements(textMarshalerType) {
return textMarshalerEncoder
}
switch t.Kind() {
case reflect.Bool:
return boolEncoder
case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
return intEncoder
case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Uintptr:
return uintEncoder
case reflect.Float32:
return float32Encoder
case reflect.Float64:
return float64Encoder
case reflect.String:
return stringEncoder
case reflect.Interface:
return interfaceEncoder
case reflect.Struct:
return newStructEncoder(t)
case reflect.Map:
return newMapEncoder(t)
case reflect.Slice:
return newSliceEncoder(t)
case reflect.Array:
return newArrayEncoder(t)
case reflect.Pointer:
return newPtrEncoder(t)
default:
return unsupportedTypeEncoder
}
}
func invalidValueEncoder(e *encodeState, v reflect.Value, _ encOpts) {
e.WriteString("null")
}
func marshalerEncoder(e *encodeState, v reflect.Value, opts encOpts) {
if v.Kind() == reflect.Pointer && v.IsNil() {
e.WriteString("null")
return
}
m, ok := v.Interface().(Marshaler)
if !ok {
e.WriteString("null")
return
}
b, err := m.MarshalJSON()
if err == nil {
e.Grow(len(b))
out := e.AvailableBuffer()
out, err = appendCompact(out, b, opts.escapeHTML)
e.Buffer.Write(out)
}
if err != nil {
e.error(&MarshalerError{v.Type(), err, "MarshalJSON"})
}
}
func addrMarshalerEncoder(e *encodeState, v reflect.Value, opts encOpts) {
va := v.Addr()
if va.IsNil() {
e.WriteString("null")
return
}
m := va.Interface().(Marshaler)
b, err := m.MarshalJSON()
if err == nil {
e.Grow(len(b))
out := e.AvailableBuffer()
out, err = appendCompact(out, b, opts.escapeHTML)
e.Buffer.Write(out)
}
if err != nil {
e.error(&MarshalerError{v.Type(), err, "MarshalJSON"})
}
}
func textMarshalerEncoder(e *encodeState, v reflect.Value, opts encOpts) {
if v.Kind() == reflect.Pointer && v.IsNil() {
e.WriteString("null")
return
}
m, ok := v.Interface().(encoding.TextMarshaler)
if !ok {
e.WriteString("null")
return
}
b, err := m.MarshalText()
if err != nil {
e.error(&MarshalerError{v.Type(), err, "MarshalText"})
}
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
e.Write(appendString(e.AvailableBuffer(), b, opts.escapeHTML))
}
func addrTextMarshalerEncoder(e *encodeState, v reflect.Value, opts encOpts) {
va := v.Addr()
if va.IsNil() {
e.WriteString("null")
return
}
m := va.Interface().(encoding.TextMarshaler)
b, err := m.MarshalText()
if err != nil {
e.error(&MarshalerError{v.Type(), err, "MarshalText"})
}
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
e.Write(appendString(e.AvailableBuffer(), b, opts.escapeHTML))
}
func boolEncoder(e *encodeState, v reflect.Value, opts encOpts) {
encoding/json: use append-like operations for encoding As part of the effort to rely less on bytes.Buffer, switch most operations to use more natural append-like operations. This makes it easier to swap bytes.Buffer out with a buffer type that only needs to support a minimal subset of operations. As a simplification, we can remove the use of the scratch buffer and use the available capacity of the buffer itself as the scratch. Also, declare an inlineable mayAppendQuote function to conditionally append a double-quote if necessary. Performance: name old time/op new time/op delta CodeEncoder 405µs ± 2% 397µs ± 2% -1.94% (p=0.000 n=20+20) CodeEncoderError 453µs ± 1% 444µs ± 4% -1.83% (p=0.000 n=19+19) CodeMarshal 559µs ± 4% 548µs ± 2% -2.02% (p=0.001 n=19+17) CodeMarshalError 724µs ± 3% 716µs ± 2% -1.13% (p=0.030 n=19+20) EncodeMarshaler 24.9ns ±15% 22.9ns ± 5% ~ (p=0.086 n=20+17) EncoderEncode 14.0ns ±27% 15.0ns ±20% ~ (p=0.365 n=20+20) There is a slight performance gain across the board due to the elimination of the scratch buffer. Appends are done directly into the unused capacity of the underlying buffer, avoiding an additional copy. See #53685 Updates #27735 Change-Id: Icf6d612a7f7a51ecd10097af092762dd1225d49e Reviewed-on: https://go-review.googlesource.com/c/go/+/469558 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 19:05:12 -08:00
b := e.AvailableBuffer()
b = mayAppendQuote(b, opts.quoted)
b = strconv.AppendBool(b, v.Bool())
b = mayAppendQuote(b, opts.quoted)
e.Write(b)
}
func intEncoder(e *encodeState, v reflect.Value, opts encOpts) {
encoding/json: use append-like operations for encoding As part of the effort to rely less on bytes.Buffer, switch most operations to use more natural append-like operations. This makes it easier to swap bytes.Buffer out with a buffer type that only needs to support a minimal subset of operations. As a simplification, we can remove the use of the scratch buffer and use the available capacity of the buffer itself as the scratch. Also, declare an inlineable mayAppendQuote function to conditionally append a double-quote if necessary. Performance: name old time/op new time/op delta CodeEncoder 405µs ± 2% 397µs ± 2% -1.94% (p=0.000 n=20+20) CodeEncoderError 453µs ± 1% 444µs ± 4% -1.83% (p=0.000 n=19+19) CodeMarshal 559µs ± 4% 548µs ± 2% -2.02% (p=0.001 n=19+17) CodeMarshalError 724µs ± 3% 716µs ± 2% -1.13% (p=0.030 n=19+20) EncodeMarshaler 24.9ns ±15% 22.9ns ± 5% ~ (p=0.086 n=20+17) EncoderEncode 14.0ns ±27% 15.0ns ±20% ~ (p=0.365 n=20+20) There is a slight performance gain across the board due to the elimination of the scratch buffer. Appends are done directly into the unused capacity of the underlying buffer, avoiding an additional copy. See #53685 Updates #27735 Change-Id: Icf6d612a7f7a51ecd10097af092762dd1225d49e Reviewed-on: https://go-review.googlesource.com/c/go/+/469558 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 19:05:12 -08:00
b := e.AvailableBuffer()
b = mayAppendQuote(b, opts.quoted)
b = strconv.AppendInt(b, v.Int(), 10)
b = mayAppendQuote(b, opts.quoted)
e.Write(b)
}
func uintEncoder(e *encodeState, v reflect.Value, opts encOpts) {
encoding/json: use append-like operations for encoding As part of the effort to rely less on bytes.Buffer, switch most operations to use more natural append-like operations. This makes it easier to swap bytes.Buffer out with a buffer type that only needs to support a minimal subset of operations. As a simplification, we can remove the use of the scratch buffer and use the available capacity of the buffer itself as the scratch. Also, declare an inlineable mayAppendQuote function to conditionally append a double-quote if necessary. Performance: name old time/op new time/op delta CodeEncoder 405µs ± 2% 397µs ± 2% -1.94% (p=0.000 n=20+20) CodeEncoderError 453µs ± 1% 444µs ± 4% -1.83% (p=0.000 n=19+19) CodeMarshal 559µs ± 4% 548µs ± 2% -2.02% (p=0.001 n=19+17) CodeMarshalError 724µs ± 3% 716µs ± 2% -1.13% (p=0.030 n=19+20) EncodeMarshaler 24.9ns ±15% 22.9ns ± 5% ~ (p=0.086 n=20+17) EncoderEncode 14.0ns ±27% 15.0ns ±20% ~ (p=0.365 n=20+20) There is a slight performance gain across the board due to the elimination of the scratch buffer. Appends are done directly into the unused capacity of the underlying buffer, avoiding an additional copy. See #53685 Updates #27735 Change-Id: Icf6d612a7f7a51ecd10097af092762dd1225d49e Reviewed-on: https://go-review.googlesource.com/c/go/+/469558 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 19:05:12 -08:00
b := e.AvailableBuffer()
b = mayAppendQuote(b, opts.quoted)
b = strconv.AppendUint(b, v.Uint(), 10)
b = mayAppendQuote(b, opts.quoted)
e.Write(b)
}
type floatEncoder int // number of bits
func (bits floatEncoder) encode(e *encodeState, v reflect.Value, opts encOpts) {
f := v.Float()
if math.IsInf(f, 0) || math.IsNaN(f) {
e.error(&UnsupportedValueError{v, strconv.FormatFloat(f, 'g', -1, int(bits))})
}
// Convert as if by ES6 number to string conversion.
// This matches most other JSON generators.
// See golang.org/issue/6384 and golang.org/issue/14135.
// Like fmt %g, but the exponent cutoffs are different
// and exponents themselves are not padded to two digits.
encoding/json: use append-like operations for encoding As part of the effort to rely less on bytes.Buffer, switch most operations to use more natural append-like operations. This makes it easier to swap bytes.Buffer out with a buffer type that only needs to support a minimal subset of operations. As a simplification, we can remove the use of the scratch buffer and use the available capacity of the buffer itself as the scratch. Also, declare an inlineable mayAppendQuote function to conditionally append a double-quote if necessary. Performance: name old time/op new time/op delta CodeEncoder 405µs ± 2% 397µs ± 2% -1.94% (p=0.000 n=20+20) CodeEncoderError 453µs ± 1% 444µs ± 4% -1.83% (p=0.000 n=19+19) CodeMarshal 559µs ± 4% 548µs ± 2% -2.02% (p=0.001 n=19+17) CodeMarshalError 724µs ± 3% 716µs ± 2% -1.13% (p=0.030 n=19+20) EncodeMarshaler 24.9ns ±15% 22.9ns ± 5% ~ (p=0.086 n=20+17) EncoderEncode 14.0ns ±27% 15.0ns ±20% ~ (p=0.365 n=20+20) There is a slight performance gain across the board due to the elimination of the scratch buffer. Appends are done directly into the unused capacity of the underlying buffer, avoiding an additional copy. See #53685 Updates #27735 Change-Id: Icf6d612a7f7a51ecd10097af092762dd1225d49e Reviewed-on: https://go-review.googlesource.com/c/go/+/469558 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 19:05:12 -08:00
b := e.AvailableBuffer()
b = mayAppendQuote(b, opts.quoted)
abs := math.Abs(f)
fmt := byte('f')
// Note: Must use float32 comparisons for underlying float32 value to get precise cutoffs right.
if abs != 0 {
if bits == 64 && (abs < 1e-6 || abs >= 1e21) || bits == 32 && (float32(abs) < 1e-6 || float32(abs) >= 1e21) {
fmt = 'e'
}
}
b = strconv.AppendFloat(b, f, fmt, -1, int(bits))
if fmt == 'e' {
// clean up e-09 to e-9
n := len(b)
if n >= 4 && b[n-4] == 'e' && b[n-3] == '-' && b[n-2] == '0' {
b[n-2] = b[n-1]
b = b[:n-1]
}
}
encoding/json: use append-like operations for encoding As part of the effort to rely less on bytes.Buffer, switch most operations to use more natural append-like operations. This makes it easier to swap bytes.Buffer out with a buffer type that only needs to support a minimal subset of operations. As a simplification, we can remove the use of the scratch buffer and use the available capacity of the buffer itself as the scratch. Also, declare an inlineable mayAppendQuote function to conditionally append a double-quote if necessary. Performance: name old time/op new time/op delta CodeEncoder 405µs ± 2% 397µs ± 2% -1.94% (p=0.000 n=20+20) CodeEncoderError 453µs ± 1% 444µs ± 4% -1.83% (p=0.000 n=19+19) CodeMarshal 559µs ± 4% 548µs ± 2% -2.02% (p=0.001 n=19+17) CodeMarshalError 724µs ± 3% 716µs ± 2% -1.13% (p=0.030 n=19+20) EncodeMarshaler 24.9ns ±15% 22.9ns ± 5% ~ (p=0.086 n=20+17) EncoderEncode 14.0ns ±27% 15.0ns ±20% ~ (p=0.365 n=20+20) There is a slight performance gain across the board due to the elimination of the scratch buffer. Appends are done directly into the unused capacity of the underlying buffer, avoiding an additional copy. See #53685 Updates #27735 Change-Id: Icf6d612a7f7a51ecd10097af092762dd1225d49e Reviewed-on: https://go-review.googlesource.com/c/go/+/469558 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 19:05:12 -08:00
b = mayAppendQuote(b, opts.quoted)
e.Write(b)
}
var (
float32Encoder = (floatEncoder(32)).encode
float64Encoder = (floatEncoder(64)).encode
)
func stringEncoder(e *encodeState, v reflect.Value, opts encOpts) {
if v.Type() == numberType {
numStr := v.String()
// In Go1.5 the empty string encodes to "0", while this is not a valid number literal
// we keep compatibility so check validity after this.
if numStr == "" {
numStr = "0" // Number's zero-val
}
if !isValidNumber(numStr) {
e.error(fmt.Errorf("json: invalid number literal %q", numStr))
}
encoding/json: use append-like operations for encoding As part of the effort to rely less on bytes.Buffer, switch most operations to use more natural append-like operations. This makes it easier to swap bytes.Buffer out with a buffer type that only needs to support a minimal subset of operations. As a simplification, we can remove the use of the scratch buffer and use the available capacity of the buffer itself as the scratch. Also, declare an inlineable mayAppendQuote function to conditionally append a double-quote if necessary. Performance: name old time/op new time/op delta CodeEncoder 405µs ± 2% 397µs ± 2% -1.94% (p=0.000 n=20+20) CodeEncoderError 453µs ± 1% 444µs ± 4% -1.83% (p=0.000 n=19+19) CodeMarshal 559µs ± 4% 548µs ± 2% -2.02% (p=0.001 n=19+17) CodeMarshalError 724µs ± 3% 716µs ± 2% -1.13% (p=0.030 n=19+20) EncodeMarshaler 24.9ns ±15% 22.9ns ± 5% ~ (p=0.086 n=20+17) EncoderEncode 14.0ns ±27% 15.0ns ±20% ~ (p=0.365 n=20+20) There is a slight performance gain across the board due to the elimination of the scratch buffer. Appends are done directly into the unused capacity of the underlying buffer, avoiding an additional copy. See #53685 Updates #27735 Change-Id: Icf6d612a7f7a51ecd10097af092762dd1225d49e Reviewed-on: https://go-review.googlesource.com/c/go/+/469558 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 19:05:12 -08:00
b := e.AvailableBuffer()
b = mayAppendQuote(b, opts.quoted)
b = append(b, numStr...)
b = mayAppendQuote(b, opts.quoted)
e.Write(b)
return
}
if opts.quoted {
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
b := appendString(nil, v.String(), opts.escapeHTML)
e.Write(appendString(e.AvailableBuffer(), b, false)) // no need to escape again since it is already escaped
} else {
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
e.Write(appendString(e.AvailableBuffer(), v.String(), opts.escapeHTML))
}
}
// isValidNumber reports whether s is a valid JSON number literal.
func isValidNumber(s string) bool {
// This function implements the JSON numbers grammar.
// See https://tools.ietf.org/html/rfc7159#section-6
// and https://www.json.org/img/number.png
if s == "" {
return false
}
// Optional -
if s[0] == '-' {
s = s[1:]
if s == "" {
return false
}
}
// Digits
switch {
default:
return false
case s[0] == '0':
s = s[1:]
case '1' <= s[0] && s[0] <= '9':
s = s[1:]
for len(s) > 0 && '0' <= s[0] && s[0] <= '9' {
s = s[1:]
}
}
// . followed by 1 or more digits.
if len(s) >= 2 && s[0] == '.' && '0' <= s[1] && s[1] <= '9' {
s = s[2:]
for len(s) > 0 && '0' <= s[0] && s[0] <= '9' {
s = s[1:]
}
}
// e or E followed by an optional - or + and
// 1 or more digits.
if len(s) >= 2 && (s[0] == 'e' || s[0] == 'E') {
s = s[1:]
if s[0] == '+' || s[0] == '-' {
s = s[1:]
if s == "" {
return false
}
}
for len(s) > 0 && '0' <= s[0] && s[0] <= '9' {
s = s[1:]
}
}
// Make sure we are at the end.
return s == ""
}
func interfaceEncoder(e *encodeState, v reflect.Value, opts encOpts) {
if v.IsNil() {
e.WriteString("null")
return
}
e.reflectValue(v.Elem(), opts)
}
func unsupportedTypeEncoder(e *encodeState, v reflect.Value, _ encOpts) {
e.error(&UnsupportedTypeError{v.Type()})
}
type structEncoder struct {
encoding/json: index names for the struct decoder In the common case, structs have a handful of fields and most inputs match struct field names exactly. The previous code would do a linear search over the fields, stopping at the first exact match, and otherwise using the first case insensitive match. This is unfortunate, because it means that for the common case, we'd do a linear search with bytes.Equal. Even for structs with only two or three fields, that is pretty wasteful. Worse even, up until the exact match was found via the linear search, all previous fields would run their equalFold functions, which aren't cheap even in the simple case. Instead, cache a map along with the field list that indexes the fields by their name. This way, a case sensitive field search doesn't involve a linear search, nor does it involve any equalFold func calls. This patch should also slightly speed up cases where there's a case insensitive match but not a case sensitive one, as then we'd avoid calling bytes.Equal on all the fields. Though that's not a common case, and there are no benchmarks for it. name old time/op new time/op delta CodeDecoder-8 11.0ms ± 0% 10.6ms ± 1% -4.42% (p=0.000 n=9+10) name old speed new speed delta CodeDecoder-8 176MB/s ± 0% 184MB/s ± 1% +4.62% (p=0.000 n=9+10) name old alloc/op new alloc/op delta CodeDecoder-8 2.28MB ± 0% 2.28MB ± 0% ~ (p=0.725 n=10+10) name old allocs/op new allocs/op delta CodeDecoder-8 76.9k ± 0% 76.9k ± 0% ~ (all equal) Updates #28923. Change-Id: I9929c1f06c76505e5b96914199315dbdaae5dc76 Reviewed-on: https://go-review.googlesource.com/c/go/+/172918 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-04-22 23:36:43 +07:00
fields structFields
}
type structFields struct {
encoding/json: simplify folded name logic The folded name logic (despite all attempts to optimize it) was fundamentally an O(n) operation where every field in a struct needed to be linearly scanned in order to find a match. This made unmashaling of unknown fields always O(n). Instead of optimizing the comparison for each field, make it such that we can look up a name in O(1). We accomplish this by maintaining a map keyed by pre-folded names, which we can pre-calculate when processing the struct type. Using a stack-allocated buffer, we can fold the input name and look up its presence in the map. Also, instead of mapping from names to indexes, map directly to a pointer to the field information. The memory cost of this is the same and avoids an extra slice index. The new logic is both simpler and faster. Performance: name old time/op new time/op delta CodeDecoder 2.47ms ± 4% 2.42ms ± 2% -1.83% (p=0.022 n=10+9) UnicodeDecoder 259ns ± 2% 248ns ± 1% -4.32% (p=0.000 n=10+10) DecoderStream 150ns ± 1% 149ns ± 1% ~ (p=0.516 n=10+10) CodeUnmarshal 3.13ms ± 2% 3.09ms ± 2% -1.37% (p=0.022 n=10+9) CodeUnmarshalReuse 2.50ms ± 1% 2.45ms ± 1% -1.96% (p=0.001 n=8+9) UnmarshalString 67.1ns ± 5% 64.5ns ± 5% -3.90% (p=0.005 n=10+10) UnmarshalFloat64 60.1ns ± 4% 58.4ns ± 2% -2.89% (p=0.002 n=10+8) UnmarshalInt64 51.0ns ± 4% 49.2ns ± 1% -3.53% (p=0.001 n=10+8) Issue10335 80.7ns ± 2% 79.2ns ± 1% -1.82% (p=0.016 n=10+8) Issue34127 28.6ns ± 3% 28.8ns ± 3% ~ (p=0.388 n=9+10) Unmapped 177ns ± 2% 177ns ± 2% ~ (p=0.956 n=10+10) Change-Id: I478b2b958f5a63a69c9a991a39cd5ffb43244a2a Reviewed-on: https://go-review.googlesource.com/c/go/+/471196 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
2023-02-20 11:26:10 -08:00
list []field
byExactName map[string]*field
byFoldedName map[string]*field
}
func (se structEncoder) encode(e *encodeState, v reflect.Value, opts encOpts) {
next := byte('{')
FieldLoop:
encoding/json: index names for the struct decoder In the common case, structs have a handful of fields and most inputs match struct field names exactly. The previous code would do a linear search over the fields, stopping at the first exact match, and otherwise using the first case insensitive match. This is unfortunate, because it means that for the common case, we'd do a linear search with bytes.Equal. Even for structs with only two or three fields, that is pretty wasteful. Worse even, up until the exact match was found via the linear search, all previous fields would run their equalFold functions, which aren't cheap even in the simple case. Instead, cache a map along with the field list that indexes the fields by their name. This way, a case sensitive field search doesn't involve a linear search, nor does it involve any equalFold func calls. This patch should also slightly speed up cases where there's a case insensitive match but not a case sensitive one, as then we'd avoid calling bytes.Equal on all the fields. Though that's not a common case, and there are no benchmarks for it. name old time/op new time/op delta CodeDecoder-8 11.0ms ± 0% 10.6ms ± 1% -4.42% (p=0.000 n=9+10) name old speed new speed delta CodeDecoder-8 176MB/s ± 0% 184MB/s ± 1% +4.62% (p=0.000 n=9+10) name old alloc/op new alloc/op delta CodeDecoder-8 2.28MB ± 0% 2.28MB ± 0% ~ (p=0.725 n=10+10) name old allocs/op new allocs/op delta CodeDecoder-8 76.9k ± 0% 76.9k ± 0% ~ (all equal) Updates #28923. Change-Id: I9929c1f06c76505e5b96914199315dbdaae5dc76 Reviewed-on: https://go-review.googlesource.com/c/go/+/172918 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-04-22 23:36:43 +07:00
for i := range se.fields.list {
f := &se.fields.list[i]
// Find the nested struct field by following f.index.
fv := v
for _, i := range f.index {
if fv.Kind() == reflect.Pointer {
if fv.IsNil() {
continue FieldLoop
}
fv = fv.Elem()
}
fv = fv.Field(i)
}
if f.omitEmpty && isEmptyValue(fv) {
continue
}
e.WriteByte(next)
next = ','
encoding/json: encode struct field names ahead of time Struct field names are static, so we can run HTMLEscape on them when building each struct type encoder. Then, when running the struct encoder, we can select either the original or the escaped field name to write directly. When the encoder is not escaping HTML, using the original string works because neither Go struct field names nor JSON tags allow any characters that would need to be escaped, like '"', '\\', or '\n'. When the encoder is escaping HTML, the only difference is that '<', '>', and '&' are allowed via JSON struct field tags, hence why we use HTMLEscape to properly escape them. All of the above lets us encode field names with a simple if/else and WriteString calls, which are considerably simpler and faster than encoding an arbitrary string. While at it, also include the quotes and colon in these strings, to avoid three WriteByte calls in the loop hot path. Also added a few tests, to ensure that the behavior in these edge cases is not broken. The output of the tests is the same if this optimization is reverted. name old time/op new time/op delta CodeEncoder-4 7.12ms ± 0% 6.14ms ± 0% -13.85% (p=0.004 n=6+5) name old speed new speed delta CodeEncoder-4 272MB/s ± 0% 316MB/s ± 0% +16.08% (p=0.004 n=6+5) name old alloc/op new alloc/op delta CodeEncoder-4 91.9kB ± 0% 93.2kB ± 0% +1.43% (p=0.002 n=6+6) name old allocs/op new allocs/op delta CodeEncoder-4 0.00 0.00 ~ (all equal) Updates #5683. Change-Id: I6f6a340d0de4670799ce38cf95b2092822d2e3ef Reviewed-on: https://go-review.googlesource.com/122460 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-07-07 15:59:20 +01:00
if opts.escapeHTML {
e.WriteString(f.nameEscHTML)
} else {
e.WriteString(f.nameNonEsc)
}
opts.quoted = f.quoted
f.encoder(e, fv, opts)
}
if next == '{' {
e.WriteString("{}")
} else {
e.WriteByte('}')
}
}
func newStructEncoder(t reflect.Type) encoderFunc {
se := structEncoder{fields: cachedTypeFields(t)}
return se.encode
}
type mapEncoder struct {
elemEnc encoderFunc
}
func (me mapEncoder) encode(e *encodeState, v reflect.Value, opts encOpts) {
if v.IsNil() {
e.WriteString("null")
return
}
if e.ptrLevel++; e.ptrLevel > startDetectingCyclesAfter {
// We're a large number of nested ptrEncoder.encode calls deep;
// start checking if we've run into a pointer cycle.
ptr := v.UnsafePointer()
if _, ok := e.ptrSeen[ptr]; ok {
e.error(&UnsupportedValueError{v, fmt.Sprintf("encountered a cycle via %s", v.Type())})
}
e.ptrSeen[ptr] = struct{}{}
defer delete(e.ptrSeen, ptr)
}
e.WriteByte('{')
// Extract and sort the keys.
sv := make([]reflectWithString, v.Len())
mi := v.MapRange()
for i := 0; mi.Next(); i++ {
sv[i].k = mi.Key()
sv[i].v = mi.Value()
if err := sv[i].resolve(); err != nil {
e.error(fmt.Errorf("json: encoding error for type %q: %q", v.Type().String(), err.Error()))
}
}
sort.Slice(sv, func(i, j int) bool { return sv[i].ks < sv[j].ks })
for i, kv := range sv {
if i > 0 {
e.WriteByte(',')
}
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
e.Write(appendString(e.AvailableBuffer(), kv.ks, opts.escapeHTML))
e.WriteByte(':')
me.elemEnc(e, kv.v, opts)
}
e.WriteByte('}')
e.ptrLevel--
}
func newMapEncoder(t reflect.Type) encoderFunc {
switch t.Key().Kind() {
case reflect.String,
reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64,
reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Uintptr:
default:
if !t.Key().Implements(textMarshalerType) {
return unsupportedTypeEncoder
}
}
me := mapEncoder{typeEncoder(t.Elem())}
return me.encode
}
func encodeByteSlice(e *encodeState, v reflect.Value, _ encOpts) {
if v.IsNil() {
e.WriteString("null")
return
}
s := v.Bytes()
encodedLen := base64.StdEncoding.EncodedLen(len(s))
encoding/json: use append-like operations for encoding As part of the effort to rely less on bytes.Buffer, switch most operations to use more natural append-like operations. This makes it easier to swap bytes.Buffer out with a buffer type that only needs to support a minimal subset of operations. As a simplification, we can remove the use of the scratch buffer and use the available capacity of the buffer itself as the scratch. Also, declare an inlineable mayAppendQuote function to conditionally append a double-quote if necessary. Performance: name old time/op new time/op delta CodeEncoder 405µs ± 2% 397µs ± 2% -1.94% (p=0.000 n=20+20) CodeEncoderError 453µs ± 1% 444µs ± 4% -1.83% (p=0.000 n=19+19) CodeMarshal 559µs ± 4% 548µs ± 2% -2.02% (p=0.001 n=19+17) CodeMarshalError 724µs ± 3% 716µs ± 2% -1.13% (p=0.030 n=19+20) EncodeMarshaler 24.9ns ±15% 22.9ns ± 5% ~ (p=0.086 n=20+17) EncoderEncode 14.0ns ±27% 15.0ns ±20% ~ (p=0.365 n=20+20) There is a slight performance gain across the board due to the elimination of the scratch buffer. Appends are done directly into the unused capacity of the underlying buffer, avoiding an additional copy. See #53685 Updates #27735 Change-Id: Icf6d612a7f7a51ecd10097af092762dd1225d49e Reviewed-on: https://go-review.googlesource.com/c/go/+/469558 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 19:05:12 -08:00
e.Grow(len(`"`) + encodedLen + len(`"`))
// TODO(https://go.dev/issue/53693): Use base64.Encoding.AppendEncode.
b := e.AvailableBuffer()
b = append(b, '"')
base64.StdEncoding.Encode(b[len(b):][:encodedLen], s)
b = b[:len(b)+encodedLen]
b = append(b, '"')
e.Write(b)
}
// sliceEncoder just wraps an arrayEncoder, checking to make sure the value isn't nil.
type sliceEncoder struct {
arrayEnc encoderFunc
}
func (se sliceEncoder) encode(e *encodeState, v reflect.Value, opts encOpts) {
if v.IsNil() {
e.WriteString("null")
return
}
if e.ptrLevel++; e.ptrLevel > startDetectingCyclesAfter {
// We're a large number of nested ptrEncoder.encode calls deep;
// start checking if we've run into a pointer cycle.
// Here we use a struct to memorize the pointer to the first element of the slice
// and its length.
ptr := struct {
ptr interface{} // always an unsafe.Pointer, but avoids a dependency on package unsafe
len int
}{v.UnsafePointer(), v.Len()}
if _, ok := e.ptrSeen[ptr]; ok {
e.error(&UnsupportedValueError{v, fmt.Sprintf("encountered a cycle via %s", v.Type())})
}
e.ptrSeen[ptr] = struct{}{}
defer delete(e.ptrSeen, ptr)
}
se.arrayEnc(e, v, opts)
e.ptrLevel--
}
func newSliceEncoder(t reflect.Type) encoderFunc {
// Byte slices get special treatment; arrays don't.
if t.Elem().Kind() == reflect.Uint8 {
p := reflect.PointerTo(t.Elem())
if !p.Implements(marshalerType) && !p.Implements(textMarshalerType) {
return encodeByteSlice
}
}
enc := sliceEncoder{newArrayEncoder(t)}
return enc.encode
}
type arrayEncoder struct {
elemEnc encoderFunc
}
func (ae arrayEncoder) encode(e *encodeState, v reflect.Value, opts encOpts) {
e.WriteByte('[')
n := v.Len()
for i := 0; i < n; i++ {
if i > 0 {
e.WriteByte(',')
}
ae.elemEnc(e, v.Index(i), opts)
}
e.WriteByte(']')
}
func newArrayEncoder(t reflect.Type) encoderFunc {
enc := arrayEncoder{typeEncoder(t.Elem())}
return enc.encode
}
type ptrEncoder struct {
elemEnc encoderFunc
}
func (pe ptrEncoder) encode(e *encodeState, v reflect.Value, opts encOpts) {
if v.IsNil() {
e.WriteString("null")
return
}
encoding/json: error when encoding a pointer cycle Otherwise we'd panic with a stack overflow. Most programs are in control of the data being encoded and can ensure there are no cycles, but sometimes it's not that simple. For example, running a user's html template with script tags can easily result in crashes if the user can find a pointer cycle. Adding the checks via a map to every ptrEncoder.encode call slowed down the benchmarks below by a noticeable 13%. Instead, only start doing the relatively expensive pointer cycle checks if we're many levels of pointers deep in an encode state. A threshold of 1000 is small enough to capture pointer cycles before they're a problem (the goroutine stack limit is currently 1GB, and I needed close to a million levels to reach it). Yet it's large enough that reasonable uses of the json encoder only see a tiny 1% slow-down due to the added ptrLevel field and check. name old time/op new time/op delta CodeEncoder-8 2.34ms ± 1% 2.37ms ± 0% +1.05% (p=0.000 n=10+10) CodeMarshal-8 2.42ms ± 1% 2.44ms ± 0% +1.10% (p=0.000 n=10+10) name old speed new speed delta CodeEncoder-8 829MB/s ± 1% 820MB/s ± 0% -1.04% (p=0.000 n=10+10) CodeMarshal-8 803MB/s ± 1% 795MB/s ± 0% -1.09% (p=0.000 n=10+10) name old alloc/op new alloc/op delta CodeEncoder-8 43.1kB ± 8% 42.5kB ±10% ~ (p=0.989 n=10+10) CodeMarshal-8 1.99MB ± 0% 1.99MB ± 0% ~ (p=0.254 n=9+6) name old allocs/op new allocs/op delta CodeEncoder-8 0.00 0.00 ~ (all equal) CodeMarshal-8 1.00 ± 0% 1.00 ± 0% ~ (all equal) Finally, add a few tests to ensure that the code handles the edge cases properly. Fixes #10769. Change-Id: I73d48e0cf6ea140127ea031f2dbae6e6a55e58b8 Reviewed-on: https://go-review.googlesource.com/c/go/+/187920 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com> Reviewed-by: Andrew Bonventre <andybons@golang.org>
2019-07-28 20:16:14 -07:00
if e.ptrLevel++; e.ptrLevel > startDetectingCyclesAfter {
// We're a large number of nested ptrEncoder.encode calls deep;
// start checking if we've run into a pointer cycle.
ptr := v.Interface()
if _, ok := e.ptrSeen[ptr]; ok {
e.error(&UnsupportedValueError{v, fmt.Sprintf("encountered a cycle via %s", v.Type())})
}
e.ptrSeen[ptr] = struct{}{}
defer delete(e.ptrSeen, ptr)
}
pe.elemEnc(e, v.Elem(), opts)
encoding/json: error when encoding a pointer cycle Otherwise we'd panic with a stack overflow. Most programs are in control of the data being encoded and can ensure there are no cycles, but sometimes it's not that simple. For example, running a user's html template with script tags can easily result in crashes if the user can find a pointer cycle. Adding the checks via a map to every ptrEncoder.encode call slowed down the benchmarks below by a noticeable 13%. Instead, only start doing the relatively expensive pointer cycle checks if we're many levels of pointers deep in an encode state. A threshold of 1000 is small enough to capture pointer cycles before they're a problem (the goroutine stack limit is currently 1GB, and I needed close to a million levels to reach it). Yet it's large enough that reasonable uses of the json encoder only see a tiny 1% slow-down due to the added ptrLevel field and check. name old time/op new time/op delta CodeEncoder-8 2.34ms ± 1% 2.37ms ± 0% +1.05% (p=0.000 n=10+10) CodeMarshal-8 2.42ms ± 1% 2.44ms ± 0% +1.10% (p=0.000 n=10+10) name old speed new speed delta CodeEncoder-8 829MB/s ± 1% 820MB/s ± 0% -1.04% (p=0.000 n=10+10) CodeMarshal-8 803MB/s ± 1% 795MB/s ± 0% -1.09% (p=0.000 n=10+10) name old alloc/op new alloc/op delta CodeEncoder-8 43.1kB ± 8% 42.5kB ±10% ~ (p=0.989 n=10+10) CodeMarshal-8 1.99MB ± 0% 1.99MB ± 0% ~ (p=0.254 n=9+6) name old allocs/op new allocs/op delta CodeEncoder-8 0.00 0.00 ~ (all equal) CodeMarshal-8 1.00 ± 0% 1.00 ± 0% ~ (all equal) Finally, add a few tests to ensure that the code handles the edge cases properly. Fixes #10769. Change-Id: I73d48e0cf6ea140127ea031f2dbae6e6a55e58b8 Reviewed-on: https://go-review.googlesource.com/c/go/+/187920 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com> Reviewed-by: Andrew Bonventre <andybons@golang.org>
2019-07-28 20:16:14 -07:00
e.ptrLevel--
}
func newPtrEncoder(t reflect.Type) encoderFunc {
enc := ptrEncoder{typeEncoder(t.Elem())}
return enc.encode
}
type condAddrEncoder struct {
canAddrEnc, elseEnc encoderFunc
}
func (ce condAddrEncoder) encode(e *encodeState, v reflect.Value, opts encOpts) {
if v.CanAddr() {
ce.canAddrEnc(e, v, opts)
} else {
ce.elseEnc(e, v, opts)
}
}
// newCondAddrEncoder returns an encoder that checks whether its value
// CanAddr and delegates to canAddrEnc if so, else to elseEnc.
func newCondAddrEncoder(canAddrEnc, elseEnc encoderFunc) encoderFunc {
enc := condAddrEncoder{canAddrEnc: canAddrEnc, elseEnc: elseEnc}
return enc.encode
}
func isValidTag(s string) bool {
if s == "" {
return false
}
for _, c := range s {
switch {
case strings.ContainsRune("!#$%&()*+-./:;<=>?@[]^_{|}~ ", c):
// Backslash and quote chars are reserved, but
// otherwise any punctuation chars are allowed
// in a tag name.
case !unicode.IsLetter(c) && !unicode.IsDigit(c):
return false
}
}
return true
}
func typeByIndex(t reflect.Type, index []int) reflect.Type {
for _, i := range index {
if t.Kind() == reflect.Pointer {
t = t.Elem()
}
t = t.Field(i).Type
}
return t
}
type reflectWithString struct {
k reflect.Value
v reflect.Value
ks string
}
func (w *reflectWithString) resolve() error {
if w.k.Kind() == reflect.String {
w.ks = w.k.String()
return nil
}
if tm, ok := w.k.Interface().(encoding.TextMarshaler); ok {
if w.k.Kind() == reflect.Pointer && w.k.IsNil() {
return nil
}
buf, err := tm.MarshalText()
w.ks = string(buf)
return err
}
switch w.k.Kind() {
case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
w.ks = strconv.FormatInt(w.k.Int(), 10)
return nil
case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Uintptr:
w.ks = strconv.FormatUint(w.k.Uint(), 10)
return nil
}
panic("unexpected map key type")
}
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
func appendString[Bytes []byte | string](dst []byte, src Bytes, escapeHTML bool) []byte {
dst = append(dst, '"')
start := 0
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
for i := 0; i < len(src); {
if b := src[i]; b < utf8.RuneSelf {
encoding/json: Use a lookup table for safe characters The previous check for characters inside of a JSON string that needed to be escaped performed seven different boolean comparisons before determining that a ASCII character did not need to be escaped. Most characters do not need to be escaped, so this check can be done in a more performant way. Use the same strategy as the unicode package for precomputing a range of characters that need to be escaped, then do a single lookup into a character array to determine whether the character needs escaping. On an AWS c4.large node: $ benchstat benchmarks/master-bench benchmarks/json-table-bench name old time/op new time/op delta CodeEncoder-2 19.0ms ± 0% 15.5ms ± 1% -18.16% (p=0.000 n=19+20) CodeMarshal-2 20.1ms ± 1% 16.8ms ± 2% -16.35% (p=0.000 n=20+21) CodeDecoder-2 49.3ms ± 1% 49.5ms ± 2% ~ (p=0.498 n=16+20) DecoderStream-2 416ns ± 0% 416ns ± 1% ~ (p=0.978 n=19+19) CodeUnmarshal-2 51.0ms ± 1% 50.9ms ± 1% ~ (p=0.490 n=19+17) CodeUnmarshalReuse-2 48.5ms ± 2% 48.5ms ± 2% ~ (p=0.989 n=20+19) UnmarshalString-2 541ns ± 1% 532ns ± 1% -1.75% (p=0.000 n=20+21) UnmarshalFloat64-2 485ns ± 1% 481ns ± 1% -0.92% (p=0.000 n=20+21) UnmarshalInt64-2 429ns ± 1% 427ns ± 1% -0.49% (p=0.000 n=19+20) Issue10335-2 631ns ± 1% 619ns ± 1% -1.84% (p=0.000 n=20+20) NumberIsValid-2 19.1ns ± 0% 19.1ns ± 0% ~ (all samples are equal) NumberIsValidRegexp-2 689ns ± 1% 690ns ± 0% ~ (p=0.150 n=20+20) SkipValue-2 14.0ms ± 0% 14.0ms ± 0% -0.05% (p=0.000 n=18+18) EncoderEncode-2 525ns ± 2% 512ns ± 1% -2.33% (p=0.000 n=20+18) name old speed new speed delta CodeEncoder-2 102MB/s ± 0% 125MB/s ± 1% +22.20% (p=0.000 n=19+20) CodeMarshal-2 96.6MB/s ± 1% 115.6MB/s ± 2% +19.56% (p=0.000 n=20+21) CodeDecoder-2 39.3MB/s ± 1% 39.2MB/s ± 2% ~ (p=0.464 n=16+20) CodeUnmarshal-2 38.1MB/s ± 1% 38.1MB/s ± 1% ~ (p=0.525 n=19+17) SkipValue-2 143MB/s ± 0% 143MB/s ± 0% +0.05% (p=0.000 n=18+18) I also took the data set reported in #5683 (browser telemetry data from Mozilla), added named structs for the data set, and turned it into a proper benchmark: https://github.com/kevinburke/jsonbench/blob/master/go/bench_test.go The results from that test are similarly encouraging. On a 64-bit Mac: $ benchstat benchmarks/master-benchmark benchmarks/json-table-benchmark name old time/op new time/op delta CodeMarshal-4 1.19ms ± 2% 1.08ms ± 2% -9.33% (p=0.000 n=21+17) Unmarshal-4 3.09ms ± 3% 3.06ms ± 1% -0.83% (p=0.027 n=22+17) UnmarshalReuse-4 3.04ms ± 1% 3.04ms ± 1% ~ (p=0.169 n=20+15) name old speed new speed delta CodeMarshal-4 80.3MB/s ± 1% 88.5MB/s ± 1% +10.29% (p=0.000 n=21+17) Unmarshal-4 31.0MB/s ± 2% 31.2MB/s ± 1% +0.83% (p=0.025 n=22+17) On the c4.large: $ benchstat benchmarks/master-bench benchmarks/json-table-bench name old time/op new time/op delta CodeMarshal-2 1.10ms ± 1% 0.98ms ± 1% -10.12% (p=0.000 n=20+54) Unmarshal-2 2.82ms ± 1% 2.79ms ± 0% -1.09% (p=0.000 n=20+51) UnmarshalReuse-2 2.80ms ± 0% 2.77ms ± 0% -1.03% (p=0.000 n=20+52) name old speed new speed delta CodeMarshal-2 87.3MB/s ± 1% 97.1MB/s ± 1% +11.27% (p=0.000 n=20+54) Unmarshal-2 33.9MB/s ± 1% 34.2MB/s ± 0% +1.10% (p=0.000 n=20+51) For what it's worth, I tried other heuristics - short circuiting the conditional for common ASCII characters, for example: if (b >= 63 && b != 92) || (b >= 39 && b <= 59) || (rest of the conditional) This offered a speedup around 7-9%, not as large as the submitted change. Change-Id: Idcf88f7b93bfcd1164cdd6a585160b7e407a0d9b Reviewed-on: https://go-review.googlesource.com/24466 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-06-26 09:47:43 -07:00
if htmlSafeSet[b] || (!escapeHTML && safeSet[b]) {
i++
continue
}
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
dst = append(dst, src[start:i]...)
switch b {
case '\\', '"':
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
dst = append(dst, '\\', b)
case '\n':
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
dst = append(dst, '\\', 'n')
case '\r':
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
dst = append(dst, '\\', 'r')
case '\t':
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
dst = append(dst, '\\', 't')
default:
// This encodes bytes < 0x20 except for \t, \n and \r.
// If escapeHTML is set, it also escapes <, >, and &
// because they can lead to security holes when
// user-controlled strings are rendered into JSON
// and served to some browsers.
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
dst = append(dst, '\\', 'u', '0', '0', hex[b>>4], hex[b&0xF])
}
i++
start = i
continue
}
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
// TODO(https://go.dev/issue/56948): Use generic utf8 functionality.
// For now, cast only a small portion of byte slices to a string
// so that it can be stack allocated. This slows down []byte slightly
// due to the extra copy, but keeps string performance roughly the same.
n := len(src) - i
if n > utf8.UTFMax {
n = utf8.UTFMax
}
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
c, size := utf8.DecodeRuneInString(string(src[i : i+n]))
if c == utf8.RuneError && size == 1 {
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
dst = append(dst, src[start:i]...)
dst = append(dst, `\ufffd`...)
i += size
start = i
continue
}
// U+2028 is LINE SEPARATOR.
// U+2029 is PARAGRAPH SEPARATOR.
// They are both technically valid characters in JSON strings,
// but don't work in JSONP, which has to be evaluated as JavaScript,
// and can lead to security holes there. It is valid JSON to
// escape them, so we do so unconditionally.
// See https://en.wikipedia.org/wiki/JSON#Safety.
if c == '\u2028' || c == '\u2029' {
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
dst = append(dst, src[start:i]...)
dst = append(dst, '\\', 'u', '2', '0', '2', hex[c&0xF])
i += size
start = i
continue
}
i += size
}
encoding/json: unify encodeState.string and encodeState.stringBytes This is part of the effort to reduce direct reliance on bytes.Buffer so that we can use a buffer with better pooling characteristics. Unify these two methods as a single version that uses generics to reduce duplicated logic. Unfortunately, we lack a generic version of utf8.DecodeRune (see #56948), so we cast []byte to string. The []byte variant is slightly slower for multi-byte unicode since casting results in a stack-allocated copy operation. Fortunately, this code path is used only for TextMarshalers. We can also delete TestStringBytes, which exists to ensure that the two duplicate implementations remain in sync. Performance: name old time/op new time/op delta CodeEncoder 399µs ± 2% 409µs ± 2% +2.59% (p=0.000 n=9+9) CodeEncoderError 450µs ± 1% 451µs ± 2% ~ (p=0.684 n=10+10) CodeMarshal 553µs ± 2% 562µs ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 733µs ± 3% 737µs ± 2% ~ (p=0.400 n=9+10) EncodeMarshaler 24.9ns ±12% 24.1ns ±13% ~ (p=0.190 n=10+10) EncoderEncode 12.3ns ± 3% 14.7ns ±20% ~ (p=0.315 n=8+10) name old speed new speed delta CodeEncoder 4.87GB/s ± 2% 4.74GB/s ± 2% -2.53% (p=0.000 n=9+9) CodeEncoderError 4.31GB/s ± 1% 4.30GB/s ± 2% ~ (p=0.684 n=10+10) CodeMarshal 3.51GB/s ± 2% 3.46GB/s ± 3% ~ (p=0.075 n=10+10) CodeMarshalError 2.65GB/s ± 3% 2.63GB/s ± 2% ~ (p=0.400 n=9+10) name old alloc/op new alloc/op delta CodeEncoder 327B ±347% 447B ±232% +36.93% (p=0.034 n=9+10) CodeEncoderError 142B ± 1% 143B ± 0% ~ (p=1.000 n=8+7) CodeMarshal 1.96MB ± 2% 1.96MB ± 2% ~ (p=0.468 n=10+10) CodeMarshalError 2.04MB ± 3% 2.03MB ± 1% ~ (p=0.971 n=10+10) EncodeMarshaler 4.00B ± 0% 4.00B ± 0% ~ (all equal) EncoderEncode 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta CodeEncoder 0.00 0.00 ~ (all equal) CodeEncoderError 4.00 ± 0% 4.00 ± 0% ~ (all equal) CodeMarshal 1.00 ± 0% 1.00 ± 0% ~ (all equal) CodeMarshalError 6.00 ± 0% 6.00 ± 0% ~ (all equal) EncodeMarshaler 1.00 ± 0% 1.00 ± 0% ~ (all equal) EncoderEncode 0.00 0.00 ~ (all equal) There is a very slight performance degradation for CodeEncoder due to an increase in allocation sizes. However, the number of allocations did not change. This is likely due to remote effects of the growth rate differences between bytes.Buffer and the builtin append function. We shouldn't overly rely on the growth rate of bytes.Buffer anyways since that is subject to possibly change in #51462. As the benchtime increases, the alloc/op goes down indicating that the amortized memory cost is fixed. Updates #27735 Change-Id: Ie35e480e292fe082d7986e0a4d81212c1d4202b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/469556 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 17:37:02 -08:00
dst = append(dst, src[start:]...)
dst = append(dst, '"')
return dst
}
// A field represents a single field found in a struct.
type field struct {
name string
encoding/json: simplify folded name logic The folded name logic (despite all attempts to optimize it) was fundamentally an O(n) operation where every field in a struct needed to be linearly scanned in order to find a match. This made unmashaling of unknown fields always O(n). Instead of optimizing the comparison for each field, make it such that we can look up a name in O(1). We accomplish this by maintaining a map keyed by pre-folded names, which we can pre-calculate when processing the struct type. Using a stack-allocated buffer, we can fold the input name and look up its presence in the map. Also, instead of mapping from names to indexes, map directly to a pointer to the field information. The memory cost of this is the same and avoids an extra slice index. The new logic is both simpler and faster. Performance: name old time/op new time/op delta CodeDecoder 2.47ms ± 4% 2.42ms ± 2% -1.83% (p=0.022 n=10+9) UnicodeDecoder 259ns ± 2% 248ns ± 1% -4.32% (p=0.000 n=10+10) DecoderStream 150ns ± 1% 149ns ± 1% ~ (p=0.516 n=10+10) CodeUnmarshal 3.13ms ± 2% 3.09ms ± 2% -1.37% (p=0.022 n=10+9) CodeUnmarshalReuse 2.50ms ± 1% 2.45ms ± 1% -1.96% (p=0.001 n=8+9) UnmarshalString 67.1ns ± 5% 64.5ns ± 5% -3.90% (p=0.005 n=10+10) UnmarshalFloat64 60.1ns ± 4% 58.4ns ± 2% -2.89% (p=0.002 n=10+8) UnmarshalInt64 51.0ns ± 4% 49.2ns ± 1% -3.53% (p=0.001 n=10+8) Issue10335 80.7ns ± 2% 79.2ns ± 1% -1.82% (p=0.016 n=10+8) Issue34127 28.6ns ± 3% 28.8ns ± 3% ~ (p=0.388 n=9+10) Unmapped 177ns ± 2% 177ns ± 2% ~ (p=0.956 n=10+10) Change-Id: I478b2b958f5a63a69c9a991a39cd5ffb43244a2a Reviewed-on: https://go-review.googlesource.com/c/go/+/471196 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
2023-02-20 11:26:10 -08:00
nameBytes []byte // []byte(name)
encoding/json: encode struct field names ahead of time Struct field names are static, so we can run HTMLEscape on them when building each struct type encoder. Then, when running the struct encoder, we can select either the original or the escaped field name to write directly. When the encoder is not escaping HTML, using the original string works because neither Go struct field names nor JSON tags allow any characters that would need to be escaped, like '"', '\\', or '\n'. When the encoder is escaping HTML, the only difference is that '<', '>', and '&' are allowed via JSON struct field tags, hence why we use HTMLEscape to properly escape them. All of the above lets us encode field names with a simple if/else and WriteString calls, which are considerably simpler and faster than encoding an arbitrary string. While at it, also include the quotes and colon in these strings, to avoid three WriteByte calls in the loop hot path. Also added a few tests, to ensure that the behavior in these edge cases is not broken. The output of the tests is the same if this optimization is reverted. name old time/op new time/op delta CodeEncoder-4 7.12ms ± 0% 6.14ms ± 0% -13.85% (p=0.004 n=6+5) name old speed new speed delta CodeEncoder-4 272MB/s ± 0% 316MB/s ± 0% +16.08% (p=0.004 n=6+5) name old alloc/op new alloc/op delta CodeEncoder-4 91.9kB ± 0% 93.2kB ± 0% +1.43% (p=0.002 n=6+6) name old allocs/op new allocs/op delta CodeEncoder-4 0.00 0.00 ~ (all equal) Updates #5683. Change-Id: I6f6a340d0de4670799ce38cf95b2092822d2e3ef Reviewed-on: https://go-review.googlesource.com/122460 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-07-07 15:59:20 +01:00
nameNonEsc string // `"` + name + `":`
nameEscHTML string // `"` + HTMLEscape(name) + `":`
tag bool
index []int
typ reflect.Type
omitEmpty bool
quoted bool
encoder encoderFunc
}
// byIndex sorts field by index sequence.
type byIndex []field
func (x byIndex) Len() int { return len(x) }
func (x byIndex) Swap(i, j int) { x[i], x[j] = x[j], x[i] }
func (x byIndex) Less(i, j int) bool {
for k, xik := range x[i].index {
if k >= len(x[j].index) {
return false
}
if xik != x[j].index[k] {
return xik < x[j].index[k]
}
}
return len(x[i].index) < len(x[j].index)
}
// typeFields returns a list of fields that JSON should recognize for the given type.
// The algorithm is breadth-first search over the set of structs to include - the top struct
// and then any reachable anonymous structs.
encoding/json: index names for the struct decoder In the common case, structs have a handful of fields and most inputs match struct field names exactly. The previous code would do a linear search over the fields, stopping at the first exact match, and otherwise using the first case insensitive match. This is unfortunate, because it means that for the common case, we'd do a linear search with bytes.Equal. Even for structs with only two or three fields, that is pretty wasteful. Worse even, up until the exact match was found via the linear search, all previous fields would run their equalFold functions, which aren't cheap even in the simple case. Instead, cache a map along with the field list that indexes the fields by their name. This way, a case sensitive field search doesn't involve a linear search, nor does it involve any equalFold func calls. This patch should also slightly speed up cases where there's a case insensitive match but not a case sensitive one, as then we'd avoid calling bytes.Equal on all the fields. Though that's not a common case, and there are no benchmarks for it. name old time/op new time/op delta CodeDecoder-8 11.0ms ± 0% 10.6ms ± 1% -4.42% (p=0.000 n=9+10) name old speed new speed delta CodeDecoder-8 176MB/s ± 0% 184MB/s ± 1% +4.62% (p=0.000 n=9+10) name old alloc/op new alloc/op delta CodeDecoder-8 2.28MB ± 0% 2.28MB ± 0% ~ (p=0.725 n=10+10) name old allocs/op new allocs/op delta CodeDecoder-8 76.9k ± 0% 76.9k ± 0% ~ (all equal) Updates #28923. Change-Id: I9929c1f06c76505e5b96914199315dbdaae5dc76 Reviewed-on: https://go-review.googlesource.com/c/go/+/172918 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-04-22 23:36:43 +07:00
func typeFields(t reflect.Type) structFields {
// Anonymous fields to explore at the current level and the next.
current := []field{}
next := []field{{typ: t}}
// Count of queued names for current level and the next.
var count, nextCount map[reflect.Type]int
// Types already visited at an earlier level.
visited := map[reflect.Type]bool{}
// Fields found.
var fields []field
// Buffer to run appendHTMLEscape on field names.
var nameEscBuf []byte
encoding/json: encode struct field names ahead of time Struct field names are static, so we can run HTMLEscape on them when building each struct type encoder. Then, when running the struct encoder, we can select either the original or the escaped field name to write directly. When the encoder is not escaping HTML, using the original string works because neither Go struct field names nor JSON tags allow any characters that would need to be escaped, like '"', '\\', or '\n'. When the encoder is escaping HTML, the only difference is that '<', '>', and '&' are allowed via JSON struct field tags, hence why we use HTMLEscape to properly escape them. All of the above lets us encode field names with a simple if/else and WriteString calls, which are considerably simpler and faster than encoding an arbitrary string. While at it, also include the quotes and colon in these strings, to avoid three WriteByte calls in the loop hot path. Also added a few tests, to ensure that the behavior in these edge cases is not broken. The output of the tests is the same if this optimization is reverted. name old time/op new time/op delta CodeEncoder-4 7.12ms ± 0% 6.14ms ± 0% -13.85% (p=0.004 n=6+5) name old speed new speed delta CodeEncoder-4 272MB/s ± 0% 316MB/s ± 0% +16.08% (p=0.004 n=6+5) name old alloc/op new alloc/op delta CodeEncoder-4 91.9kB ± 0% 93.2kB ± 0% +1.43% (p=0.002 n=6+6) name old allocs/op new allocs/op delta CodeEncoder-4 0.00 0.00 ~ (all equal) Updates #5683. Change-Id: I6f6a340d0de4670799ce38cf95b2092822d2e3ef Reviewed-on: https://go-review.googlesource.com/122460 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-07-07 15:59:20 +01:00
for len(next) > 0 {
current, next = next, current[:0]
count, nextCount = nextCount, map[reflect.Type]int{}
for _, f := range current {
if visited[f.typ] {
continue
}
visited[f.typ] = true
// Scan f.typ for fields to include.
for i := 0; i < f.typ.NumField(); i++ {
sf := f.typ.Field(i)
if sf.Anonymous {
t := sf.Type
if t.Kind() == reflect.Pointer {
t = t.Elem()
}
if !sf.IsExported() && t.Kind() != reflect.Struct {
// Ignore embedded fields of unexported non-struct types.
continue
}
// Do not ignore embedded fields of unexported struct types
// since they may have exported fields.
} else if !sf.IsExported() {
// Ignore unexported non-embedded fields.
continue
}
tag := sf.Tag.Get("json")
if tag == "-" {
continue
}
name, opts := parseTag(tag)
if !isValidTag(name) {
name = ""
}
index := make([]int, len(f.index)+1)
copy(index, f.index)
index[len(f.index)] = i
ft := sf.Type
if ft.Name() == "" && ft.Kind() == reflect.Pointer {
// Follow pointer.
ft = ft.Elem()
}
// Only strings, floats, integers, and booleans can be quoted.
quoted := false
if opts.Contains("string") {
switch ft.Kind() {
case reflect.Bool,
reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64,
reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Uintptr,
reflect.Float32, reflect.Float64,
reflect.String:
quoted = true
}
}
// Record found field and index sequence.
if name != "" || !sf.Anonymous || ft.Kind() != reflect.Struct {
tagged := name != ""
if name == "" {
name = sf.Name
}
field := field{
name: name,
tag: tagged,
index: index,
typ: ft,
omitEmpty: opts.Contains("omitempty"),
quoted: quoted,
}
field.nameBytes = []byte(field.name)
encoding/json: encode struct field names ahead of time Struct field names are static, so we can run HTMLEscape on them when building each struct type encoder. Then, when running the struct encoder, we can select either the original or the escaped field name to write directly. When the encoder is not escaping HTML, using the original string works because neither Go struct field names nor JSON tags allow any characters that would need to be escaped, like '"', '\\', or '\n'. When the encoder is escaping HTML, the only difference is that '<', '>', and '&' are allowed via JSON struct field tags, hence why we use HTMLEscape to properly escape them. All of the above lets us encode field names with a simple if/else and WriteString calls, which are considerably simpler and faster than encoding an arbitrary string. While at it, also include the quotes and colon in these strings, to avoid three WriteByte calls in the loop hot path. Also added a few tests, to ensure that the behavior in these edge cases is not broken. The output of the tests is the same if this optimization is reverted. name old time/op new time/op delta CodeEncoder-4 7.12ms ± 0% 6.14ms ± 0% -13.85% (p=0.004 n=6+5) name old speed new speed delta CodeEncoder-4 272MB/s ± 0% 316MB/s ± 0% +16.08% (p=0.004 n=6+5) name old alloc/op new alloc/op delta CodeEncoder-4 91.9kB ± 0% 93.2kB ± 0% +1.43% (p=0.002 n=6+6) name old allocs/op new allocs/op delta CodeEncoder-4 0.00 0.00 ~ (all equal) Updates #5683. Change-Id: I6f6a340d0de4670799ce38cf95b2092822d2e3ef Reviewed-on: https://go-review.googlesource.com/122460 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-07-07 15:59:20 +01:00
// Build nameEscHTML and nameNonEsc ahead of time.
nameEscBuf = appendHTMLEscape(nameEscBuf[:0], field.nameBytes)
field.nameEscHTML = `"` + string(nameEscBuf) + `":`
encoding/json: encode struct field names ahead of time Struct field names are static, so we can run HTMLEscape on them when building each struct type encoder. Then, when running the struct encoder, we can select either the original or the escaped field name to write directly. When the encoder is not escaping HTML, using the original string works because neither Go struct field names nor JSON tags allow any characters that would need to be escaped, like '"', '\\', or '\n'. When the encoder is escaping HTML, the only difference is that '<', '>', and '&' are allowed via JSON struct field tags, hence why we use HTMLEscape to properly escape them. All of the above lets us encode field names with a simple if/else and WriteString calls, which are considerably simpler and faster than encoding an arbitrary string. While at it, also include the quotes and colon in these strings, to avoid three WriteByte calls in the loop hot path. Also added a few tests, to ensure that the behavior in these edge cases is not broken. The output of the tests is the same if this optimization is reverted. name old time/op new time/op delta CodeEncoder-4 7.12ms ± 0% 6.14ms ± 0% -13.85% (p=0.004 n=6+5) name old speed new speed delta CodeEncoder-4 272MB/s ± 0% 316MB/s ± 0% +16.08% (p=0.004 n=6+5) name old alloc/op new alloc/op delta CodeEncoder-4 91.9kB ± 0% 93.2kB ± 0% +1.43% (p=0.002 n=6+6) name old allocs/op new allocs/op delta CodeEncoder-4 0.00 0.00 ~ (all equal) Updates #5683. Change-Id: I6f6a340d0de4670799ce38cf95b2092822d2e3ef Reviewed-on: https://go-review.googlesource.com/122460 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-07-07 15:59:20 +01:00
field.nameNonEsc = `"` + field.name + `":`
fields = append(fields, field)
if count[f.typ] > 1 {
// If there were multiple instances, add a second,
// so that the annihilation code will see a duplicate.
// It only cares about the distinction between 1 or 2,
// so don't bother generating any more copies.
fields = append(fields, fields[len(fields)-1])
}
continue
}
// Record new anonymous struct to explore in next round.
nextCount[ft]++
if nextCount[ft] == 1 {
next = append(next, field{name: ft.Name(), index: index, typ: ft})
}
}
}
}
sort.Slice(fields, func(i, j int) bool {
x := fields
// sort field by name, breaking ties with depth, then
// breaking ties with "name came from json tag", then
// breaking ties with index sequence.
if x[i].name != x[j].name {
return x[i].name < x[j].name
}
if len(x[i].index) != len(x[j].index) {
return len(x[i].index) < len(x[j].index)
}
if x[i].tag != x[j].tag {
return x[i].tag
}
return byIndex(x).Less(i, j)
})
// Delete all fields that are hidden by the Go rules for embedded fields,
// except that fields with JSON tags are promoted.
// The fields are sorted in primary order of name, secondary order
// of field index length. Loop over names; for each name, delete
// hidden fields by choosing the one dominant field that survives.
out := fields[:0]
for advance, i := 0, 0; i < len(fields); i += advance {
// One iteration per name.
// Find the sequence of fields with the name of this first field.
fi := fields[i]
name := fi.name
for advance = 1; i+advance < len(fields); advance++ {
fj := fields[i+advance]
if fj.name != name {
break
}
}
if advance == 1 { // Only one field with this name
out = append(out, fi)
continue
}
dominant, ok := dominantField(fields[i : i+advance])
if ok {
out = append(out, dominant)
}
}
fields = out
sort.Sort(byIndex(fields))
for i := range fields {
f := &fields[i]
f.encoder = typeEncoder(typeByIndex(t, f.index))
}
encoding/json: simplify folded name logic The folded name logic (despite all attempts to optimize it) was fundamentally an O(n) operation where every field in a struct needed to be linearly scanned in order to find a match. This made unmashaling of unknown fields always O(n). Instead of optimizing the comparison for each field, make it such that we can look up a name in O(1). We accomplish this by maintaining a map keyed by pre-folded names, which we can pre-calculate when processing the struct type. Using a stack-allocated buffer, we can fold the input name and look up its presence in the map. Also, instead of mapping from names to indexes, map directly to a pointer to the field information. The memory cost of this is the same and avoids an extra slice index. The new logic is both simpler and faster. Performance: name old time/op new time/op delta CodeDecoder 2.47ms ± 4% 2.42ms ± 2% -1.83% (p=0.022 n=10+9) UnicodeDecoder 259ns ± 2% 248ns ± 1% -4.32% (p=0.000 n=10+10) DecoderStream 150ns ± 1% 149ns ± 1% ~ (p=0.516 n=10+10) CodeUnmarshal 3.13ms ± 2% 3.09ms ± 2% -1.37% (p=0.022 n=10+9) CodeUnmarshalReuse 2.50ms ± 1% 2.45ms ± 1% -1.96% (p=0.001 n=8+9) UnmarshalString 67.1ns ± 5% 64.5ns ± 5% -3.90% (p=0.005 n=10+10) UnmarshalFloat64 60.1ns ± 4% 58.4ns ± 2% -2.89% (p=0.002 n=10+8) UnmarshalInt64 51.0ns ± 4% 49.2ns ± 1% -3.53% (p=0.001 n=10+8) Issue10335 80.7ns ± 2% 79.2ns ± 1% -1.82% (p=0.016 n=10+8) Issue34127 28.6ns ± 3% 28.8ns ± 3% ~ (p=0.388 n=9+10) Unmapped 177ns ± 2% 177ns ± 2% ~ (p=0.956 n=10+10) Change-Id: I478b2b958f5a63a69c9a991a39cd5ffb43244a2a Reviewed-on: https://go-review.googlesource.com/c/go/+/471196 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
2023-02-20 11:26:10 -08:00
exactNameIndex := make(map[string]*field, len(fields))
foldedNameIndex := make(map[string]*field, len(fields))
encoding/json: index names for the struct decoder In the common case, structs have a handful of fields and most inputs match struct field names exactly. The previous code would do a linear search over the fields, stopping at the first exact match, and otherwise using the first case insensitive match. This is unfortunate, because it means that for the common case, we'd do a linear search with bytes.Equal. Even for structs with only two or three fields, that is pretty wasteful. Worse even, up until the exact match was found via the linear search, all previous fields would run their equalFold functions, which aren't cheap even in the simple case. Instead, cache a map along with the field list that indexes the fields by their name. This way, a case sensitive field search doesn't involve a linear search, nor does it involve any equalFold func calls. This patch should also slightly speed up cases where there's a case insensitive match but not a case sensitive one, as then we'd avoid calling bytes.Equal on all the fields. Though that's not a common case, and there are no benchmarks for it. name old time/op new time/op delta CodeDecoder-8 11.0ms ± 0% 10.6ms ± 1% -4.42% (p=0.000 n=9+10) name old speed new speed delta CodeDecoder-8 176MB/s ± 0% 184MB/s ± 1% +4.62% (p=0.000 n=9+10) name old alloc/op new alloc/op delta CodeDecoder-8 2.28MB ± 0% 2.28MB ± 0% ~ (p=0.725 n=10+10) name old allocs/op new allocs/op delta CodeDecoder-8 76.9k ± 0% 76.9k ± 0% ~ (all equal) Updates #28923. Change-Id: I9929c1f06c76505e5b96914199315dbdaae5dc76 Reviewed-on: https://go-review.googlesource.com/c/go/+/172918 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-04-22 23:36:43 +07:00
for i, field := range fields {
encoding/json: simplify folded name logic The folded name logic (despite all attempts to optimize it) was fundamentally an O(n) operation where every field in a struct needed to be linearly scanned in order to find a match. This made unmashaling of unknown fields always O(n). Instead of optimizing the comparison for each field, make it such that we can look up a name in O(1). We accomplish this by maintaining a map keyed by pre-folded names, which we can pre-calculate when processing the struct type. Using a stack-allocated buffer, we can fold the input name and look up its presence in the map. Also, instead of mapping from names to indexes, map directly to a pointer to the field information. The memory cost of this is the same and avoids an extra slice index. The new logic is both simpler and faster. Performance: name old time/op new time/op delta CodeDecoder 2.47ms ± 4% 2.42ms ± 2% -1.83% (p=0.022 n=10+9) UnicodeDecoder 259ns ± 2% 248ns ± 1% -4.32% (p=0.000 n=10+10) DecoderStream 150ns ± 1% 149ns ± 1% ~ (p=0.516 n=10+10) CodeUnmarshal 3.13ms ± 2% 3.09ms ± 2% -1.37% (p=0.022 n=10+9) CodeUnmarshalReuse 2.50ms ± 1% 2.45ms ± 1% -1.96% (p=0.001 n=8+9) UnmarshalString 67.1ns ± 5% 64.5ns ± 5% -3.90% (p=0.005 n=10+10) UnmarshalFloat64 60.1ns ± 4% 58.4ns ± 2% -2.89% (p=0.002 n=10+8) UnmarshalInt64 51.0ns ± 4% 49.2ns ± 1% -3.53% (p=0.001 n=10+8) Issue10335 80.7ns ± 2% 79.2ns ± 1% -1.82% (p=0.016 n=10+8) Issue34127 28.6ns ± 3% 28.8ns ± 3% ~ (p=0.388 n=9+10) Unmapped 177ns ± 2% 177ns ± 2% ~ (p=0.956 n=10+10) Change-Id: I478b2b958f5a63a69c9a991a39cd5ffb43244a2a Reviewed-on: https://go-review.googlesource.com/c/go/+/471196 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
2023-02-20 11:26:10 -08:00
exactNameIndex[field.name] = &fields[i]
// For historical reasons, first folded match takes precedence.
if _, ok := foldedNameIndex[string(foldName(field.nameBytes))]; !ok {
foldedNameIndex[string(foldName(field.nameBytes))] = &fields[i]
}
encoding/json: index names for the struct decoder In the common case, structs have a handful of fields and most inputs match struct field names exactly. The previous code would do a linear search over the fields, stopping at the first exact match, and otherwise using the first case insensitive match. This is unfortunate, because it means that for the common case, we'd do a linear search with bytes.Equal. Even for structs with only two or three fields, that is pretty wasteful. Worse even, up until the exact match was found via the linear search, all previous fields would run their equalFold functions, which aren't cheap even in the simple case. Instead, cache a map along with the field list that indexes the fields by their name. This way, a case sensitive field search doesn't involve a linear search, nor does it involve any equalFold func calls. This patch should also slightly speed up cases where there's a case insensitive match but not a case sensitive one, as then we'd avoid calling bytes.Equal on all the fields. Though that's not a common case, and there are no benchmarks for it. name old time/op new time/op delta CodeDecoder-8 11.0ms ± 0% 10.6ms ± 1% -4.42% (p=0.000 n=9+10) name old speed new speed delta CodeDecoder-8 176MB/s ± 0% 184MB/s ± 1% +4.62% (p=0.000 n=9+10) name old alloc/op new alloc/op delta CodeDecoder-8 2.28MB ± 0% 2.28MB ± 0% ~ (p=0.725 n=10+10) name old allocs/op new allocs/op delta CodeDecoder-8 76.9k ± 0% 76.9k ± 0% ~ (all equal) Updates #28923. Change-Id: I9929c1f06c76505e5b96914199315dbdaae5dc76 Reviewed-on: https://go-review.googlesource.com/c/go/+/172918 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-04-22 23:36:43 +07:00
}
encoding/json: simplify folded name logic The folded name logic (despite all attempts to optimize it) was fundamentally an O(n) operation where every field in a struct needed to be linearly scanned in order to find a match. This made unmashaling of unknown fields always O(n). Instead of optimizing the comparison for each field, make it such that we can look up a name in O(1). We accomplish this by maintaining a map keyed by pre-folded names, which we can pre-calculate when processing the struct type. Using a stack-allocated buffer, we can fold the input name and look up its presence in the map. Also, instead of mapping from names to indexes, map directly to a pointer to the field information. The memory cost of this is the same and avoids an extra slice index. The new logic is both simpler and faster. Performance: name old time/op new time/op delta CodeDecoder 2.47ms ± 4% 2.42ms ± 2% -1.83% (p=0.022 n=10+9) UnicodeDecoder 259ns ± 2% 248ns ± 1% -4.32% (p=0.000 n=10+10) DecoderStream 150ns ± 1% 149ns ± 1% ~ (p=0.516 n=10+10) CodeUnmarshal 3.13ms ± 2% 3.09ms ± 2% -1.37% (p=0.022 n=10+9) CodeUnmarshalReuse 2.50ms ± 1% 2.45ms ± 1% -1.96% (p=0.001 n=8+9) UnmarshalString 67.1ns ± 5% 64.5ns ± 5% -3.90% (p=0.005 n=10+10) UnmarshalFloat64 60.1ns ± 4% 58.4ns ± 2% -2.89% (p=0.002 n=10+8) UnmarshalInt64 51.0ns ± 4% 49.2ns ± 1% -3.53% (p=0.001 n=10+8) Issue10335 80.7ns ± 2% 79.2ns ± 1% -1.82% (p=0.016 n=10+8) Issue34127 28.6ns ± 3% 28.8ns ± 3% ~ (p=0.388 n=9+10) Unmapped 177ns ± 2% 177ns ± 2% ~ (p=0.956 n=10+10) Change-Id: I478b2b958f5a63a69c9a991a39cd5ffb43244a2a Reviewed-on: https://go-review.googlesource.com/c/go/+/471196 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
2023-02-20 11:26:10 -08:00
return structFields{fields, exactNameIndex, foldedNameIndex}
}
// dominantField looks through the fields, all of which are known to
// have the same name, to find the single field that dominates the
// others using Go's embedding rules, modified by the presence of
// JSON tags. If there are multiple top-level fields, the boolean
// will be false: This condition is an error in Go and we skip all
// the fields.
func dominantField(fields []field) (field, bool) {
// The fields are sorted in increasing index-length order, then by presence of tag.
// That means that the first field is the dominant one. We need only check
// for error cases: two fields at top level, either both tagged or neither tagged.
if len(fields) > 1 && len(fields[0].index) == len(fields[1].index) && fields[0].tag == fields[1].tag {
return field{}, false
}
return fields[0], true
}
encoding/json: index names for the struct decoder In the common case, structs have a handful of fields and most inputs match struct field names exactly. The previous code would do a linear search over the fields, stopping at the first exact match, and otherwise using the first case insensitive match. This is unfortunate, because it means that for the common case, we'd do a linear search with bytes.Equal. Even for structs with only two or three fields, that is pretty wasteful. Worse even, up until the exact match was found via the linear search, all previous fields would run their equalFold functions, which aren't cheap even in the simple case. Instead, cache a map along with the field list that indexes the fields by their name. This way, a case sensitive field search doesn't involve a linear search, nor does it involve any equalFold func calls. This patch should also slightly speed up cases where there's a case insensitive match but not a case sensitive one, as then we'd avoid calling bytes.Equal on all the fields. Though that's not a common case, and there are no benchmarks for it. name old time/op new time/op delta CodeDecoder-8 11.0ms ± 0% 10.6ms ± 1% -4.42% (p=0.000 n=9+10) name old speed new speed delta CodeDecoder-8 176MB/s ± 0% 184MB/s ± 1% +4.62% (p=0.000 n=9+10) name old alloc/op new alloc/op delta CodeDecoder-8 2.28MB ± 0% 2.28MB ± 0% ~ (p=0.725 n=10+10) name old allocs/op new allocs/op delta CodeDecoder-8 76.9k ± 0% 76.9k ± 0% ~ (all equal) Updates #28923. Change-Id: I9929c1f06c76505e5b96914199315dbdaae5dc76 Reviewed-on: https://go-review.googlesource.com/c/go/+/172918 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-04-22 23:36:43 +07:00
var fieldCache sync.Map // map[reflect.Type]structFields
// cachedTypeFields is like typeFields but uses a cache to avoid repeated work.
encoding/json: index names for the struct decoder In the common case, structs have a handful of fields and most inputs match struct field names exactly. The previous code would do a linear search over the fields, stopping at the first exact match, and otherwise using the first case insensitive match. This is unfortunate, because it means that for the common case, we'd do a linear search with bytes.Equal. Even for structs with only two or three fields, that is pretty wasteful. Worse even, up until the exact match was found via the linear search, all previous fields would run their equalFold functions, which aren't cheap even in the simple case. Instead, cache a map along with the field list that indexes the fields by their name. This way, a case sensitive field search doesn't involve a linear search, nor does it involve any equalFold func calls. This patch should also slightly speed up cases where there's a case insensitive match but not a case sensitive one, as then we'd avoid calling bytes.Equal on all the fields. Though that's not a common case, and there are no benchmarks for it. name old time/op new time/op delta CodeDecoder-8 11.0ms ± 0% 10.6ms ± 1% -4.42% (p=0.000 n=9+10) name old speed new speed delta CodeDecoder-8 176MB/s ± 0% 184MB/s ± 1% +4.62% (p=0.000 n=9+10) name old alloc/op new alloc/op delta CodeDecoder-8 2.28MB ± 0% 2.28MB ± 0% ~ (p=0.725 n=10+10) name old allocs/op new allocs/op delta CodeDecoder-8 76.9k ± 0% 76.9k ± 0% ~ (all equal) Updates #28923. Change-Id: I9929c1f06c76505e5b96914199315dbdaae5dc76 Reviewed-on: https://go-review.googlesource.com/c/go/+/172918 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-04-22 23:36:43 +07:00
func cachedTypeFields(t reflect.Type) structFields {
if f, ok := fieldCache.Load(t); ok {
encoding/json: index names for the struct decoder In the common case, structs have a handful of fields and most inputs match struct field names exactly. The previous code would do a linear search over the fields, stopping at the first exact match, and otherwise using the first case insensitive match. This is unfortunate, because it means that for the common case, we'd do a linear search with bytes.Equal. Even for structs with only two or three fields, that is pretty wasteful. Worse even, up until the exact match was found via the linear search, all previous fields would run their equalFold functions, which aren't cheap even in the simple case. Instead, cache a map along with the field list that indexes the fields by their name. This way, a case sensitive field search doesn't involve a linear search, nor does it involve any equalFold func calls. This patch should also slightly speed up cases where there's a case insensitive match but not a case sensitive one, as then we'd avoid calling bytes.Equal on all the fields. Though that's not a common case, and there are no benchmarks for it. name old time/op new time/op delta CodeDecoder-8 11.0ms ± 0% 10.6ms ± 1% -4.42% (p=0.000 n=9+10) name old speed new speed delta CodeDecoder-8 176MB/s ± 0% 184MB/s ± 1% +4.62% (p=0.000 n=9+10) name old alloc/op new alloc/op delta CodeDecoder-8 2.28MB ± 0% 2.28MB ± 0% ~ (p=0.725 n=10+10) name old allocs/op new allocs/op delta CodeDecoder-8 76.9k ± 0% 76.9k ± 0% ~ (all equal) Updates #28923. Change-Id: I9929c1f06c76505e5b96914199315dbdaae5dc76 Reviewed-on: https://go-review.googlesource.com/c/go/+/172918 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-04-22 23:36:43 +07:00
return f.(structFields)
}
f, _ := fieldCache.LoadOrStore(t, typeFields(t))
encoding/json: index names for the struct decoder In the common case, structs have a handful of fields and most inputs match struct field names exactly. The previous code would do a linear search over the fields, stopping at the first exact match, and otherwise using the first case insensitive match. This is unfortunate, because it means that for the common case, we'd do a linear search with bytes.Equal. Even for structs with only two or three fields, that is pretty wasteful. Worse even, up until the exact match was found via the linear search, all previous fields would run their equalFold functions, which aren't cheap even in the simple case. Instead, cache a map along with the field list that indexes the fields by their name. This way, a case sensitive field search doesn't involve a linear search, nor does it involve any equalFold func calls. This patch should also slightly speed up cases where there's a case insensitive match but not a case sensitive one, as then we'd avoid calling bytes.Equal on all the fields. Though that's not a common case, and there are no benchmarks for it. name old time/op new time/op delta CodeDecoder-8 11.0ms ± 0% 10.6ms ± 1% -4.42% (p=0.000 n=9+10) name old speed new speed delta CodeDecoder-8 176MB/s ± 0% 184MB/s ± 1% +4.62% (p=0.000 n=9+10) name old alloc/op new alloc/op delta CodeDecoder-8 2.28MB ± 0% 2.28MB ± 0% ~ (p=0.725 n=10+10) name old allocs/op new allocs/op delta CodeDecoder-8 76.9k ± 0% 76.9k ± 0% ~ (all equal) Updates #28923. Change-Id: I9929c1f06c76505e5b96914199315dbdaae5dc76 Reviewed-on: https://go-review.googlesource.com/c/go/+/172918 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-04-22 23:36:43 +07:00
return f.(structFields)
}
encoding/json: use append-like operations for encoding As part of the effort to rely less on bytes.Buffer, switch most operations to use more natural append-like operations. This makes it easier to swap bytes.Buffer out with a buffer type that only needs to support a minimal subset of operations. As a simplification, we can remove the use of the scratch buffer and use the available capacity of the buffer itself as the scratch. Also, declare an inlineable mayAppendQuote function to conditionally append a double-quote if necessary. Performance: name old time/op new time/op delta CodeEncoder 405µs ± 2% 397µs ± 2% -1.94% (p=0.000 n=20+20) CodeEncoderError 453µs ± 1% 444µs ± 4% -1.83% (p=0.000 n=19+19) CodeMarshal 559µs ± 4% 548µs ± 2% -2.02% (p=0.001 n=19+17) CodeMarshalError 724µs ± 3% 716µs ± 2% -1.13% (p=0.030 n=19+20) EncodeMarshaler 24.9ns ±15% 22.9ns ± 5% ~ (p=0.086 n=20+17) EncoderEncode 14.0ns ±27% 15.0ns ±20% ~ (p=0.365 n=20+20) There is a slight performance gain across the board due to the elimination of the scratch buffer. Appends are done directly into the unused capacity of the underlying buffer, avoiding an additional copy. See #53685 Updates #27735 Change-Id: Icf6d612a7f7a51ecd10097af092762dd1225d49e Reviewed-on: https://go-review.googlesource.com/c/go/+/469558 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
2023-02-19 19:05:12 -08:00
func mayAppendQuote(b []byte, quoted bool) []byte {
if quoted {
b = append(b, '"')
}
return b
}