| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://golang.org/cl/33773 fixes the JSON marshaler to avoid serializing
embedded fields on unexported types of non-struct types. However, Go allows
embedding pointer to types, so the check for whether the field is a non-struct
type must first dereference the pointer to get at the underlying type.
Furthermore, due to a edge-case in the behavior of StructField.PkgPath not
being a reliable indicator of whether the field is unexported (see #21122),
we use our own logic to determine whether the field is exported or not.
The logic in this CL may be simplified depending on what happens in #21122.
Fixes #21121
Updates #21122
Change-Id: I8dfd1cdfac8a87950df294a566fb96dfd04fd749
Reviewed-on: https://go-review.googlesource.com/50711
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Marshal must process unexported embedded fields of struct type,
looking for exported fields in those structs. However, it must
not process unexported embedded fields of non-struct type.
For example, consider:
type t1 struct {
X int
}
type t2 int
type T struct {
t1
t2
}
When considering T, Marshal must process t1 to find t1.X.
Marshal must not process t2, but it was. Fix that.
Fixes #18009
Change-Id: I62ba0b65ba30fd927990e101a26405a9998787a3
Reviewed-on: https://go-review.googlesource.com/33773
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes #17743.
Change-Id: Ib5afb6248bb060f2ad8dd3d5f78e95271af62a57
Reviewed-on: https://go-review.googlesource.com/33135
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Caleb Spare <cespare@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
Fixes #16042.
Change-Id: I0a28aa004246b7b0ffaaab457e077ad9035363c2
Reviewed-on: https://go-review.googlesource.com/31932
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Struct fields can be suppressed in JSON serialization by "-" tags, but
that doesn't preclude generation of "-" object keys.
Document and verify the mechanism for doing so.
Change-Id: I7f60e1759cfee15cb7b2447cd35fab91c5b004e6
Reviewed-on: https://go-review.googlesource.com/21204
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change float32/float64 formatting to use non-exponential form
for a slightly wider range, to more closely match ES6 JSON.stringify
and other JSON generators.
Most notably:
1e20 now formats as 100000000000000000000 (previously 1e+20)
1e-6 now formats as 0.000001 (previously 1e-06)
1e-7 now formats as 1e-7 (previously 1e-07)
This also brings the int64 and float64 formatting in line with each other,
for all shared representable values. For example both int64(1234567)
and float64(1234567) now format as "1234567", where before the
float64 formatted as "1.234567e+06".
The only variation now compared to ES6 JSON.stringify is that
Go continues to encode negative zero as "-0", not "0", so that
the value continues to be preserved during JSON round trips.
Fixes #6384.
Fixes #14135.
Change-Id: Ib0e0e009cd9181d75edc0424a28fe776bcc5bbf8
Reviewed-on: https://go-review.googlesource.com/30371
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I avoided anywhere in the compiler or things which might be used by
the compiler in the future, since they need to build with Go 1.4.
I also avoided anywhere where there was no benefit to changing it.
I probably missed some.
Updates #16721
Change-Id: Ib3c895ff475c6dec2d4322393faaf8cb6a6d4956
Reviewed-on: https://go-review.googlesource.com/30250
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Documentation made reference to an unknown entity "DisableHTMLEscaping,"
but I think it actually meant the method "Encoder.SetEscapeHTML."
Fixes #17255
Change-Id: I18fda76f8066110caef85fd33698de83d632e646
Reviewed-on: https://go-review.googlesource.com/29931
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Swtich from a sync.RWMutex to atomic.Value for cacheTypeFields.
On GOARCH=386, this recovers most of the remaining performance
difference from the 1.6 release. Compared with tip on linux/386:
name old time/op new time/op delta
CodeDecoder-40 92.8ms ± 1% 87.7ms ± 1% -5.50% (p=0.000 n=10+10)
name old speed new speed delta
CodeDecoder-40 20.9MB/s ± 1% 22.1MB/s ± 1% +5.83% (p=0.000 n=10+10)
With more time and care, I believe more of the JSON decoder's work
could be shifted so it is done before decoding, and independent of
the number of bytes processed. Maybe someone could explore that for
Go 1.8.
For #16117.
Change-Id: I049655b2e5b76384a0d5f4b90e3ec7cc8d8c4340
Reviewed-on: https://go-review.googlesource.com/24472
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This has been inaccurate since https://golang.org/cl/6048047.
Fixes #15317.
Change-Id: If93d2161f51ccb91912cb94a35318cf33f4d526a
Reviewed-on: https://go-review.googlesource.com/23691
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CL 19725 changed the encoding of []typedByte to look for
typedByte.MarshalJSON and typedByte.MarshalText.
Previously it was handled like []byte, producing a base64 encoding of the underlying byte data.
CL 19725 forgot to look for (*typedByte).MarshalJSON and (*typedByte).MarshalText,
as the marshaling of other slices would. Add test and fix for those.
This CL also adds tests that the decoder can handle both the old and new encodings.
(This was true even in Go 1.6, which is the only reason we can consider this
not an incompatible change.)
For #13783.
Change-Id: I7cab8b6c0154a7f2d09335b7fa23173bcf856c37
Reviewed-on: https://go-review.googlesource.com/23294
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
| |
|
|
|
|
|
|
| |
Fixes #15424
Change-Id: Ib9e97509f5ac239ee54fe6fe37152a7f5fc75087
Reviewed-on: https://go-review.googlesource.com/23109
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes encoding and decoding support integer types in map
keys, converting to/from JSON string keys.
JSON object keys are still sorted lexically, even though the keys may be
integer strings.
For backwards-compatibility, the existing Text(Un)Marshaler support for
map keys (added in CL 20356) does not take precedence over the default
encoding for string types. There is no such concern for integer types,
so integer map key encoding is only used as a fallback if the map key
type is not a Text(Un)Marshaler.
Fixes #12529.
Change-Id: I7e68c34f9cd19704b1d233a9862da15fabf0908a
Reviewed-on: https://go-review.googlesource.com/22060
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This provides a way to disable the escaping of <, >, and & in JSON
strings.
Fixes #14749.
Change-Id: I1afeb0244455fc8b06c6cce920444532f229555b
Reviewed-on: https://go-review.googlesource.com/21796
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In JSON terminology, "object" is a collect of key/value pairs. But a
JSON object is only one type of JSON value (others are string, number,
array, true, false, null).
This updates the Go docs (at least the public godoc) to not use
"object" when we mean any JSON value.
Change-Id: Ieb1c456c703693714d63d9d09d306f4d9e8f4597
Reviewed-on: https://go-review.googlesource.com/22003
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
| |
|
|
|
|
|
|
|
|
| |
Fixes #13783.
Change-Id: I0122c1f0cf4075acabf5f58241bded1835699dc1
Reviewed-on: https://go-review.googlesource.com/19725
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL allows JSON-encoding & -decoding maps whose keys are types that
implement encoding.TextMarshaler / TextUnmarshaler.
During encode, the map keys are marshaled upfront so that they can be
sorted.
Fixes #12146
Change-Id: I43809750a7ad82a3603662f095c7baf75fd172da
Reviewed-on: https://go-review.googlesource.com/20356
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a subset of https://golang.org/cl/20022 with only the copyright
header lines, so the next CL will be smaller and more reviewable.
Go policy has been single space after periods in comments for some time.
The copyright header template at:
https://golang.org/doc/contribute.html#copyright
also uses a single space.
Make them all consistent.
Change-Id: Icc26c6b8495c3820da6b171ca96a74701b4a01b0
Reviewed-on: https://go-review.googlesource.com/20111
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
| |
|
|
|
|
|
|
|
|
| |
Followup to CL 12250.
For #10281.
Change-Id: If25d9cac92f10327bb355f2d11b00c625b464661
Reviewed-on: https://go-review.googlesource.com/17199
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
| |
|
|
|
|
|
|
|
|
| |
json.Number is a special case which didn't have any checks and could result in invalid JSON.
Fixes #10281
Change-Id: Ie3e726e4d6bf6a6aba535d36f6107013ceac913a
Reviewed-on: https://go-review.googlesource.com/12250
Reviewed-by: Russ Cox <rsc@golang.org>
|
| |
|
|
|
|
|
|
|
|
| |
Addresses issue #12367.
Must be checked in before CL 14010.
Change-Id: I7233c3a62d4f55d0ac7e8a87df5fc4ee7beb7207
Reviewed-on: https://go-review.googlesource.com/14011
Reviewed-by: Russ Cox <rsc@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As correctly mentioned in #11883, encodeState.string and
encodeState.stringBytes never return an error.
This CL removes the error from the function signatures and somewhat
simplifies call sites.
Fixes #11883
Change-Id: I1d1853d09631c545b68b5eea86ff7daa2e0ca10b
Reviewed-on: https://go-review.googlesource.com/15836
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
| |
|
|
|
|
|
|
| |
Marshaler is present
Change-Id: I63da54832548c325e47dc54aaa5b5112e1f3b3ba
Reviewed-on: https://go-review.googlesource.com/15048
Reviewed-by: Rob Pike <r@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "string" option only applies for strings, floats, integers, and
booleans as per the documentation. So when decoding ignore the "string"
option if the value is not of one of the types mentioned. This matches
the Marshal step which also ignores the "string" option for invalid
types.
Fixes #9812
Change-Id: I0fb2b43d0668bc0e2985886d989abbf2252070e2
Reviewed-on: https://go-review.googlesource.com/10183
Reviewed-by: Russ Cox <rsc@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The one in misc/makerelease/makerelease.go is particularly bad and
probably warrants rotating our keys.
I didn't update old weekly notes, and reverted some changes involving
test code for now, since we're late in the Go 1.5 freeze. Otherwise,
the rest are all auto-generated changes, and all manually reviewed.
Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d
Reviewed-on: https://go-review.googlesource.com/12048
Reviewed-by: Rob Pike <r@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All slice types which have elements of kind reflect.Uint8 are marshalled
into base64 for compactness. When decoding such data into a custom type
based on []byte the decoder checked the slice kind instead of the slice
element kind, so no appropriate decoder was found.
Fixed by letting the decoder check slice element kind like the encoder.
This guarantees that already encoded data can still be successfully
decoded.
Fixes #8962.
Change-Id: Ia320d4dc2c6e9e5fe6d8dc15788c81da23d20c4f
Reviewed-on: https://go-review.googlesource.com/9371
Reviewed-by: Peter Waldschmidt <peter@waldschmidt.com>
Reviewed-by: Russ Cox <rsc@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
The comment previously was reversed in sense (it appeared to be
describing unmarshaling). I've fixed that, and added the caveat that map
keys are subject to UTF-8 coercion like other strings.
Change-Id: Id08082aa71401a6e7530a42f979fbb50bd1f4e6a
Reviewed-on: https://go-review.googlesource.com/5221
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
| |
|
|
|
|
|
|
| |
Fixes #9284
Change-Id: I0410a9ed82b861686a0a986c9ca4eeeacac8f296
Reviewed-on: https://go-review.googlesource.com/1534
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
| |
|
|
|
|
|
|
|
| |
Shorter and easier to read form for a common character.
LGTM=bradfitz
R=adg, bradfitz
CC=golang-codereviews, zimmski
https://golang.org/cl/162340043
|
| |
|
|
|
|
|
|
|
| |
Fixes #8386.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant
https://golang.org/cl/149570043
|
|
|
Preparation was in CL 134570043.
This CL contains only the effect of 'hg mv src/pkg/* src'.
For more about the move, see golang.org/s/go14nopkg.
|
