| Age | Commit message (Collapse) | Author |
|---|
|
Some WriteByte('\\') calls can be deduplicated.
fillField is used in two occasions, but it is unnecessary when adding
fields to the "next" stack, as those aren't used for the final encoding.
Inline the func with its only remaining call.
Finally, unindent a default-if block.
The performance of the encoder is unaffected:
name old time/op new time/op delta
CodeEncoder-4 6.65ms ± 1% 6.65ms ± 0% ~ (p=0.662 n=6+5)
Change-Id: Ie55baeab89abad9b9f13e9f6ca886a670c30dba9
Reviewed-on: https://go-review.googlesource.com/122461
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This function was only used in a single place - in the field encoding
loop within the struct encoder.
Inlining the function call manually lets us get rid of the call
overhead. But most importantly, it lets us simplify the logic afterward.
We no longer need to use reflect.Value{} and !fv.IsValid(), as we can
skip the field immediately.
The two factors combined (mostly just the latter) give a moderate speed
improvement to this hot loop.
name old time/op new time/op delta
CodeEncoder-4 6.01ms ± 1% 5.91ms ± 1% -1.66% (p=0.002 n=6+6)
name old speed new speed delta
CodeEncoder-4 323MB/s ± 1% 328MB/s ± 1% +1.69% (p=0.002 n=6+6)
Updates #5683.
Change-Id: I12757c325a68abb2856026cf719c122612a1f38e
Reviewed-on: https://go-review.googlesource.com/125417
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
structEncoder had two slices - the list of fields, and a list containing
the encoder for each field. structEncoder.encode then looped over the
fields, and indexed into the second slice to grab the field encoder.
However, this makes it very hard for the compiler to be able to prove
that the two slices always have the same length, and that the index
expression doesn't need a bounds check.
Merge the two slices into one to completely remove the need for bounds
checks in the hot loop.
While at it, don't copy the field elements when ranging, which greatly
speeds up the hot loop in structEncoder.
name old time/op new time/op delta
CodeEncoder-4 6.18ms ± 0% 5.56ms ± 0% -10.08% (p=0.002 n=6+6)
name old speed new speed delta
CodeEncoder-4 314MB/s ± 0% 349MB/s ± 0% +11.21% (p=0.002 n=6+6)
name old alloc/op new alloc/op delta
CodeEncoder-4 93.2kB ± 0% 62.1kB ± 0% -33.33% (p=0.002 n=6+6)
Updates #5683.
Change-Id: I0dd47783530f439b125e084aede09dda172eb1e8
Reviewed-on: https://go-review.googlesource.com/125416
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Reuse v.Type() and cachedTypeFields(t) when decoding maps and structs.
Always use the same data slices when in hot loops, to ensure that the
compiler generates good code. "for i < len(data) { use(d.data[i]) }"
makes it harder for the compiler.
Finally, do other minor clean-ups, such as deduplicating switch cases,
and using a switch instead of three chained ifs.
The decoder sees a noticeable speed-up, in particular when decoding
structs.
name old time/op new time/op delta
CodeDecoder-4 29.8ms ± 1% 27.5ms ± 0% -7.83% (p=0.002 n=6+6)
name old speed new speed delta
CodeDecoder-4 65.0MB/s ± 1% 70.6MB/s ± 0% +8.49% (p=0.002 n=6+6)
Updates #5683.
Change-Id: I9d751e22502221962da696e48996ffdeb777277d
Reviewed-on: https://go-review.googlesource.com/122468
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Calling Name on a reflect.Type is somewhat expensive, as it involves a
number of nested calls and string handling.
This cost was showing up when decoding structs, as we were calling it to
set up an error context.
We can avoid the extra work unless we do encounter an error, which makes
decoding via struct types faster.
name old time/op new time/op delta
CodeDecoder-4 31.0ms ± 1% 29.9ms ± 1% -3.69% (p=0.002 n=6+6)
name old speed new speed delta
CodeDecoder-4 62.6MB/s ± 1% 65.0MB/s ± 1% +3.83% (p=0.002 n=6+6)
Updates #5683.
Change-Id: I48a3a85ef0ba96f524b7c3e9096cb2c4589e077a
Reviewed-on: https://go-review.googlesource.com/122467
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
If the encoded bytes fit in the bootstrap array encodeState.scratch, use
that instead of allocating a new byte slice.
Also tweaked the Encoding vs Encoder heuristic to use the length of the
encoded bytes, not the length of the input bytes. Encoding is used for
allocations of up to 1024 bytes, as we measured 2048 to be the point
where it no longer provides a noticeable advantage.
Also added some benchmarks. Only the first case changes in behavior.
name old time/op new time/op delta
MarshalBytes/32-4 420ns ± 1% 383ns ± 1% -8.69% (p=0.002 n=6+6)
MarshalBytes/256-4 913ns ± 1% 915ns ± 0% ~ (p=0.580 n=5+6)
MarshalBytes/4096-4 7.72µs ± 0% 7.74µs ± 0% ~ (p=0.340 n=5+6)
name old alloc/op new alloc/op delta
MarshalBytes/32-4 112B ± 0% 64B ± 0% -42.86% (p=0.002 n=6+6)
MarshalBytes/256-4 736B ± 0% 736B ± 0% ~ (all equal)
MarshalBytes/4096-4 7.30kB ± 0% 7.30kB ± 0% ~ (all equal)
name old allocs/op new allocs/op delta
MarshalBytes/32-4 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.002 n=6+6)
MarshalBytes/256-4 2.00 ± 0% 2.00 ± 0% ~ (all equal)
MarshalBytes/4096-4 2.00 ± 0% 2.00 ± 0% ~ (all equal)
Updates #5683.
Change-Id: I5fa55c27bd7728338d770ae7c0756885ba9a5724
Reviewed-on: https://go-review.googlesource.com/122462
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
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>
|
|
Updates #26775
Change-Id: I83c9eeda59769d2f35e0cc98f3a8579861d5978b
Reviewed-on: https://go-review.googlesource.com/119715
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
The existing Decoder.tokenError implementation creates its error messages by
concatenating "invalid character " + quoteChar(c) + " " + context. All context
values however already start with a space leading to error messages containing
two spaces.
This change removes " " from the concatenation expression.
Fixes #26587
Change-Id: I93d14319396636b2a40d55053bda88c98e94a81a
GitHub-Last-Rev: 6db7e1991b15beee601f558be72a2737070d8f68
GitHub-Pull-Request: golang/go#26588
Reviewed-on: https://go-review.googlesource.com/125775
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Each URL was manually verified to ensure it did not serve up incorrect
content.
Change-Id: I4dc846227af95a73ee9a3074d0c379ff0fa955df
Reviewed-on: https://go-review.googlesource.com/115798
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
|
|
Fixes gosimple warning "if err != nil { return err };
return nil' can be simplified to 'return err"
Change-Id: Ife7f78a3a76ab7802b5561d1afec536e103b504a
Reviewed-on: https://go-review.googlesource.com/108275
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Fixes #18037
Change-Id: I20e27bcc013b00b726eb348daf5ca86b138ddcc2
Reviewed-on: https://go-review.googlesource.com/107598
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
On my system, this seems to be a significant win, with a major
reduction in allocations and minor speed improvement.
name old time/op new time/op delta
CodeMarshal 9.75ms ± 3% 9.24ms ± 1% -5.21% (p=0.001 n=5+10)
CodeMarshal-4 4.98ms ± 1% 4.71ms ± 1% -5.44% (p=0.001 n=5+10)
CodeMarshal-8 4.80ms ± 0% 4.77ms ± 1% -0.70% (p=0.012 n=5+9)
name old speed new speed delta
CodeMarshal 199MB/s ± 3% 210MB/s ± 1% +5.46% (p=0.001 n=5+10)
CodeMarshal-4 390MB/s ± 1% 412MB/s ± 1% +5.76% (p=0.001 n=5+10)
CodeMarshal-8 404MB/s ± 0% 407MB/s ± 1% +0.70% (p=0.012 n=5+9)
name old alloc/op new alloc/op delta
CodeMarshal 4.59MB ± 0% 1.96MB ± 0% -57.22% (p=0.000 n=5+9)
CodeMarshal-4 4.59MB ± 0% 2.00MB ± 0% -56.39% (p=0.000 n=5+8)
CodeMarshal-8 4.59MB ± 0% 2.06MB ± 0% -55.05% (p=0.001 n=5+9)
name old allocs/op new allocs/op delta
CodeMarshal 16.0 ± 0% 1.0 ± 0% -93.75% (p=0.000 n=5+10)
CodeMarshal-4 16.0 ± 0% 1.0 ± 0% -93.75% (p=0.000 n=5+10)
CodeMarshal-8 16.0 ± 0% 1.0 ± 0% -93.75% (p=0.000 n=5+10)
Change-Id: I9d09850d8227f523f861ae1b4ca248c4a4b16aaf
Reviewed-on: https://go-review.googlesource.com/84897
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Fixes golint warning about "if block ends with a return statement, so drop this else and outdent its block".
Change-Id: Id17ad0bf37ba939386b177b709e9e3c067d8ba21
Reviewed-on: https://go-review.googlesource.com/105736
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
The go/printer (and thus gofmt) uses a heuristic to determine
whether to break alignment between elements of an expression
list which is spread across multiple lines. The heuristic only
kicked in if the entry sizes (character length) was above a
certain threshold (20) and the ratio between the previous and
current entry size was above a certain value (4).
This heuristic worked reasonably most of the time, but also
led to unfortunate breaks in many cases where a single entry
was suddenly much smaller (or larger) then the previous one.
The behavior of gofmt was sufficiently mysterious in some of
these situations that many issues were filed against it.
The simplest solution to address this problem is to remove
the heuristic altogether and have a programmer introduce
empty lines to force different alignments if it improves
readability. The problem with that approach is that the
places where it really matters, very long tables with many
(hundreds, or more) entries, may be machine-generated and
not "post-processed" by a human (e.g., unicode/utf8/tables.go).
If a single one of those entries is overlong, the result
would be that the alignment would force all comments or
values in key:value pairs to be adjusted to that overlong
value, making the table hard to read (e.g., that entry may
not even be visible on screen and all other entries seem
spaced out too wide).
Instead, we opted for a slightly improved heuristic that
behaves much better for "normal", human-written code.
1) The threshold is increased from 20 to 40. This disables
the heuristic for many common cases yet even if the alignment
is not "ideal", 40 is not that many characters per line with
todays screens, making it very likely that the entire line
remains "visible" in an editor.
2) Changed the heuristic to not simply look at the size ratio
between current and previous line, but instead considering the
geometric mean of the sizes of the previous (aligned) lines.
This emphasizes the "overall picture" of the previous lines,
rather than a single one (which might be an outlier).
3) Changed the ratio from 4 to 2.5. Now that we ignore sizes
below 40, a ratio of 4 would mean that a new entry would have
to be 4 times bigger (160) or smaller (10) before alignment
would be broken. A ratio of 2.5 seems more sensible.
Applied updated gofmt to all of src and misc. Also tested
against several former issues that complained about this
and verified that the output for the given examples is
satisfactory (added respective test cases).
Some of the files changed because they were not gofmt-ed
in the first place.
For #644.
For #7335.
For #10392.
(and probably more related issues)
Fixes #22852.
Change-Id: I5e48b3d3b157a5cf2d649833b7297b33f43a6f6e
|
|
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>
|
|
The previous type cache is quadratic in time in the situation where
new types are continually encountered. Now that it is possible to dynamically
create new types with the reflect package, this can cause json to
perform very poorly.
Switch to sync.Map which does well when the cache has hit steady state,
but also handles occasional updates in better than quadratic time.
benchmark old ns/op new ns/op delta
BenchmarkTypeFieldsCache/MissTypes1-8 14817 16202 +9.35%
BenchmarkTypeFieldsCache/MissTypes10-8 70926 69144 -2.51%
BenchmarkTypeFieldsCache/MissTypes100-8 976467 208973 -78.60%
BenchmarkTypeFieldsCache/MissTypes1000-8 79520162 1750371 -97.80%
BenchmarkTypeFieldsCache/MissTypes10000-8 6873625837 16847806 -99.75%
BenchmarkTypeFieldsCache/HitTypes1000-8 7.51 8.80 +17.18%
BenchmarkTypeFieldsCache/HitTypes10000-8 7.58 8.68 +14.51%
The old implementation takes 12 minutes just to build a cache of size 1e5
due to the quadratic behavior. I did not bother benchmark sizes above that.
Change-Id: I5e6facc1eb8e1b80e5ca285e4dd2cc8815618dad
Reviewed-on: https://go-review.googlesource.com/76850
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Eliminates the need for an extra scanner, read undo and some other tricks.
name old time/op new time/op delta
CodeEncoder-12 1.92ms ± 0% 1.91ms ± 1% -0.65% (p=0.000 n=17+20)
CodeMarshal-12 2.13ms ± 2% 2.12ms ± 1% -0.49% (p=0.038 n=18+17)
CodeDecoder-12 8.55ms ± 2% 8.49ms ± 1% ~ (p=0.119 n=20+18)
UnicodeDecoder-12 411ns ± 0% 422ns ± 0% +2.77% (p=0.000 n=19+15)
DecoderStream-12 320ns ± 1% 307ns ± 1% -3.80% (p=0.000 n=18+20)
CodeUnmarshal-12 9.65ms ± 3% 9.58ms ± 3% ~ (p=0.157 n=20+20)
CodeUnmarshalReuse-12 8.54ms ± 3% 8.56ms ± 2% ~ (p=0.602 n=20+20)
UnmarshalString-12 110ns ± 1% 87ns ± 2% -21.53% (p=0.000 n=16+20)
UnmarshalFloat64-12 101ns ± 1% 77ns ± 2% -23.08% (p=0.000 n=19+20)
UnmarshalInt64-12 94.5ns ± 2% 68.4ns ± 1% -27.60% (p=0.000 n=20+20)
Issue10335-12 128ns ± 1% 100ns ± 1% -21.89% (p=0.000 n=19+18)
Unmapped-12 427ns ± 3% 247ns ± 4% -42.17% (p=0.000 n=20+20)
NumberIsValid-12 23.0ns ± 0% 21.7ns ± 0% -5.73% (p=0.000 n=20+20)
NumberIsValidRegexp-12 641ns ± 0% 642ns ± 0% +0.15% (p=0.003 n=19+19)
EncoderEncode-12 56.9ns ± 0% 55.0ns ± 1% -3.32% (p=0.012 n=2+17)
name old speed new speed delta
CodeEncoder-12 1.01GB/s ± 1% 1.02GB/s ± 1% +0.71% (p=0.000 n=18+20)
CodeMarshal-12 913MB/s ± 2% 917MB/s ± 1% +0.49% (p=0.038 n=18+17)
CodeDecoder-12 227MB/s ± 2% 229MB/s ± 1% ~ (p=0.110 n=20+18)
UnicodeDecoder-12 34.1MB/s ± 0% 33.1MB/s ± 0% -2.73% (p=0.000 n=19+19)
CodeUnmarshal-12 201MB/s ± 3% 203MB/s ± 3% ~ (p=0.151 n=20+20)
name old alloc/op new alloc/op delta
Issue10335-12 320B ± 0% 184B ± 0% -42.50% (p=0.000 n=20+20)
Unmapped-12 568B ± 0% 216B ± 0% -61.97% (p=0.000 n=20+20)
EncoderEncode-12 0.00B 0.00B ~ (all equal)
name old allocs/op new allocs/op delta
Issue10335-12 4.00 ± 0% 3.00 ± 0% -25.00% (p=0.000 n=20+20)
Unmapped-12 18.0 ± 0% 4.0 ± 0% -77.78% (p=0.000 n=20+20)
EncoderEncode-12 0.00 0.00 ~ (all equal)
Fixes #17914
Updates #20693
Updates #10335
Change-Id: I0459a52febb8b79c9a2991e69ed2614cf8740429
Reviewed-on: https://go-review.googlesource.com/47152
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Consider the following:
type child struct{ Field string }
type parent struct{ child }
p := new(parent)
v := reflect.ValueOf(p).Elem().Field(0)
v.Field(0).SetString("hello") // v.Field = "hello"
v = v.Addr().Elem() // v = *(&v)
v.Field(0).SetString("goodbye") // v.Field = "goodbye"
It would appear that v.Addr().Elem() should have the same value, and
that it would be safe to set "goodbye".
However, after CL 66331, any interspersed calls between Field calls
causes the RO flag to be set.
Thus, setting to "goodbye" actually causes a panic.
That CL affects decodeState.indirect which assumes that back-to-back
Value.Addr().Elem() is side-effect free. We fix that logic to keep
track of the Addr() and Elem() calls and set v back to the original
after a full round-trip has occured.
Fixes #24152
Updates #24153
Change-Id: Ie50f8fe963f00cef8515d89d1d5cbc43b76d9f9c
Reviewed-on: https://go-review.googlesource.com/97796
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Rather than only ignoring runtime.Error panics, which are a very
narrow set of possible panic values, switch it such that the json
package only captures panic values that have been properly wrapped
in a jsonError struct. This ensures that only intentional panics
originating from the json package are captured.
Fixes #23012
Change-Id: I5e85200259edd2abb1b0512ce6cc288849151a6d
Reviewed-on: https://go-review.googlesource.com/94019
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
struct types
This CL reverts CL 76851 and takes a different approach to #21357.
The changes in encode.go and encode_test.go are reverts that
rolls back the changed behavior in CL 76851 where
embedded pointers to unexported struct types were
unilaterally ignored in both marshal and unmarshal.
Instead, these fields are handled as before with the exception that
it returns an error when Unmarshal is unable to set an unexported field.
The behavior of Marshal is now unchanged with regards to #21357.
This policy maintains the greatest degree of backwards compatibility
and avoids silently discarding data the user may have expected to be present.
Fixes #21357
Change-Id: I7dc753280c99f786ac51acf7e6c0246618c8b2b1
Reviewed-on: https://go-review.googlesource.com/82135
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
It was added in CL 79995. It is unnecessarily confusing.
Change-Id: Ib8ff35b9f71b54ff99d2d6e0534c7128e1f4345a
Reviewed-on: https://go-review.googlesource.com/80035
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Existing docs mention obsolete RFC 4627. Update it with current one,
https://tools.ietf.org/html/rfc7159.
Current implementation already adhere to RFC 7159.
Fixes #22888
Change-Id: I705ec1313f6f655b3bc41d2f847b30e479bf9b15
Reviewed-on: https://go-review.googlesource.com/79995
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Manually convert hex escape sequence to rune instead of calling
strconv.ParseUint.
This inlines the unhex func from docs (and many other packages).
name old time/op new time/op delta
UnicodeDecoder-4 468ns ± 1% 402ns ± 1% -14.26% (p=0.000
n=10+10)
name old speed new speed delta
UnicodeDecoder-4 29.9MB/s ± 1% 34.8MB/s ± 1% +16.59% (p=0.000
n=10+10)
name old alloc/op new alloc/op delta
UnicodeDecoder-4 44.0B ± 0% 36.0B ± 0% -18.18% (p=0.000
n=10+10)
name old allocs/op new allocs/op delta
UnicodeDecoder-4 4.00 ± 0% 2.00 ± 0% -50.00% (p=0.000
n=10+10)
Fixes #20567
Change-Id: If350978d5bb98ff517485752184d02249f5d1f3a
Reviewed-on: https://go-review.googlesource.com/44738
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
CL 60410 fixes a bug in reflect that allows assignments to an embedded
field of a pointer to an unexported struct type.
This breaks the json package because unmarshal is now unable to assign
a newly allocated struct to such fields.
In order to be consistent in the behavior for marshal and unmarshal,
this CL changes both marshal and unmarshal to always ignore
embedded pointers to unexported structs.
Fixes #21357
Change-Id: If62ea11155555e61115ebb9cfa5305caf101bde5
Reviewed-on: https://go-review.googlesource.com/76851
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Fixes #22629
Change-Id: I31e85f9faa125ee0dfd6d3c5fa89334b00d61e6e
Reviewed-on: https://go-review.googlesource.com/76530
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Joe Tsai <joetsai@google.com>
|
|
The go repository contains a mix of github.com/golang/go/issues/xxxxx
and golang.org/issues/xxxxx URLs for references to issues in the issue
tracker. We should use one for consistency, and golang.org is preferred
in case the project moves the issue tracker in the future.
This reasoning is taken from a comment Sam Whited left on a CL I
recently opened: https://go-review.googlesource.com/c/go/+/73890.
In that CL I referenced an issue using its github.com URL, because other
tests in the file I was changing contained references to issues using
their github.com URL. Sam Whited left a comment on the CL stating I
should change it to the golang.org URL.
If new code is intended to reference issues via golang.org and not
github.com, existing code should be updated so that precedence exists
for contributors who are looking at the existing code as a guide for the
code they should write.
Change-Id: I3b9053fe38a1c56fc101a8b7fd7b8f310ba29724
Reviewed-on: https://go-review.googlesource.com/75673
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
When a SyntaxError occurs, report the current offset within the stream.
The code already accounted for the offset within the current buffer
being scanned. By including how much data was already scanned, the
current offset can be computed.
Fixes #22478
Change-Id: I91ecd4cad0b85a5c1556bc597f3ee914e769af01
Reviewed-on: https://go-review.googlesource.com/74251
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Add a DisallowUnknownFields flag to Decoder.
DisallowUnknownFields causes the Decoder to return an error when
the the decoding destination is a struct and the input contains
object keys which do not match any non-ignored, public field the
destination, including keys whose value is set to null.
Note: this fix has already been worked on in 27231, which seems
to be abandoned. This version is a slightly simpler implementation
and is up to date with the master branch.
Fixes #15314
Change-Id: I987a5857c52018df334f4d1a2360649c44a7175d
Reviewed-on: https://go-review.googlesource.com/74830
Reviewed-by: Joe Tsai <joetsai@google.com>
Run-TryBot: Joe Tsai <joetsai@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
In #10909, it was decided that "Deprecated:" is a magic string for
tools (e.g., #17056 for godoc) to detect deprecated identifiers.
Use those convention instead of custom written prose.
Change-Id: Ia514fc3c88fc502e86c6e3de361c435f4cb80b22
Reviewed-on: https://go-review.googlesource.com/70110
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
|
|
This reverts https://golang.org/cl/65930.
Fixes #22148
Change-Id: Ie0712621ed89c43bef94417fc32de9af77607760
Reviewed-on: https://go-review.googlesource.com/68430
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Remove an old comment introduced in golang.org/cl/9073.
Change-Id: I14be27ddfac987f44d839920bc4d02361a576f06
Reviewed-on: https://go-review.googlesource.com/66371
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
bytes.IndexByte can be used wherever the second argument to
strings.Index is exactly one byte long, so we do that with this change.
This avoids generating unnecessary string symbols/converison and saves
a few calls to bytes.Index.
Change-Id: If31c775790e01edfece1169e398ad6a754fb4428
Reviewed-on: https://go-review.googlesource.com/66373
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
strings.IndexByte was introduced in go1.2 and it can be used
effectively wherever the second argument to strings.Index is
exactly one byte long.
This avoids generating unnecessary string symbols and saves
a few calls to strings.Index.
Change-Id: I1ab5edb7c4ee9058084cfa57cbcc267c2597e793
Reviewed-on: https://go-review.googlesource.com/65930
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
CL 60410 fixes the compiler such that reflect.StructField.PkgPath
is non-empty if and only if the field is unexported.
Given that property, we can cleanup the logic in the json encoder
to avoid parsing the field name to detect export properties.
Updates #21122
Change-Id: Ic01b9c4ca76386774846b742b0c1b9b948f53e7c
Reviewed-on: https://go-review.googlesource.com/65550
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
Make arguments semantics clear without the need to look for
json.Indent documentation.
Change-Id: If9adfe9f477a30d426ae83790b0f2578c0a809b7
Reviewed-on: https://go-review.googlesource.com/61670
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Most of these are return values that were part of a receiving parameter,
so they're still accessible.
A few others are not, but those have never had a use.
Found with github.com/mvdan/unparam, after Kevin Burke's suggestion that
the tool should also warn about unused result parameters.
Change-Id: Id8b5ed89912a99db22027703a88bd94d0b292b8b
Reviewed-on: https://go-review.googlesource.com/55910
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Went mainly for the ones that make no sense, such as the ones
mid-sentence or after commas.
Change-Id: Ie245d2c19cc7428a06295635cf6a9482ade25ff0
Reviewed-on: https://go-review.googlesource.com/57293
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This change fixes the remaining examples where the raw strings had
suboptimal indentation (one level too many) when viewed in godoc.
Follows CL 48910.
Fixes #21026.
Change-Id: Ifc0dae3fa899a9fff8b1ff958414e2fe6852321d
Reviewed-on: https://go-review.googlesource.com/50990
Run-TryBot: Dmitri Shuralyov <shurcool@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
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>
|
|
The existing example for Decoder.Decode (Stream) had excessive
indentation in the godoc interface for the const jsonStream,
making it hard to read. This fixes the indentation in the
example_test.go to improve the readability in godoc.
Helps #21026.
Change-Id: I16f56b82182da1dcc73cca44e535a7f5695e975d
Reviewed-on: https://go-review.googlesource.com/48910
Reviewed-by: Dmitri Shuralyov <shurcool@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This reverts commit df68afd07ce67727 (https://golang.org/cl/33276)
Reason for revert: made other benchmarks worse
Fixes #20693 (details)
Updates #17914
Updates #10335
Change-Id: If451b620803ccb0536b89c76c4353d2185d57d7e
Reviewed-on: https://go-review.googlesource.com/47211
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@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>
|
|
Fixes #19526
Change-Id: Ifaaf454e0e89fdf4309118c2e2e6ac0d0a43c39d
Reviewed-on: https://go-review.googlesource.com/44711
Reviewed-by: Ian Lance Taylor <iant@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>
|
|
Don't bother with BenchmarkDecoderStream — it's doing something subtle
with the input buffer that isn't easy to replicate in a parallel test.
Results remain comparable with the non-parallel version with -cpu=1:
benchmark old ns/op new ns/op delta
BenchmarkCodeEncoder 22815832 21058729 -7.70%
BenchmarkCodeEncoder-6 22190561 3579757 -83.87%
BenchmarkCodeMarshal 25356621 25396429 +0.16%
BenchmarkCodeMarshal-6 25359813 4944908 -80.50%
BenchmarkCodeDecoder 94794556 88016360 -7.15%
BenchmarkCodeDecoder-6 93795028 16726283 -82.17%
BenchmarkDecoderStream 532 583 +9.59%
BenchmarkDecoderStream-6 598 550 -8.03%
BenchmarkCodeUnmarshal 97644168 89162504 -8.69%
BenchmarkCodeUnmarshal-6 96615302 17036419 -82.37%
BenchmarkCodeUnmarshalReuse 91747073 90298479 -1.58%
BenchmarkCodeUnmarshalReuse-6 89397165 15518005 -82.64%
BenchmarkUnmarshalString 808 843 +4.33%
BenchmarkUnmarshalString-6 912 220 -75.88%
BenchmarkUnmarshalFloat64 695 732 +5.32%
BenchmarkUnmarshalFloat64-6 710 191 -73.10%
BenchmarkUnmarshalInt64 635 640 +0.79%
BenchmarkUnmarshalInt64-6 618 185 -70.06%
BenchmarkIssue10335 916 947 +3.38%
BenchmarkIssue10335-6 879 216 -75.43%
BenchmarkNumberIsValid 34.7 34.3 -1.15%
BenchmarkNumberIsValid-6 34.9 36.7 +5.16%
BenchmarkNumberIsValidRegexp 1174 1121 -4.51%
BenchmarkNumberIsValidRegexp-6 1134 1119 -1.32%
BenchmarkSkipValue 20506938 20708060 +0.98%
BenchmarkSkipValue-6 21627665 22375630 +3.46%
BenchmarkEncoderEncode 690 726 +5.22%
BenchmarkEncoderEncode-6 649 157 -75.81%
benchmark old MB/s new MB/s speedup
BenchmarkCodeEncoder 85.05 92.15 1.08x
BenchmarkCodeEncoder-6 87.45 542.07 6.20x
BenchmarkCodeMarshal 76.53 76.41 1.00x
BenchmarkCodeMarshal-6 76.52 392.42 5.13x
BenchmarkCodeDecoder 20.47 22.05 1.08x
BenchmarkCodeDecoder-6 20.69 116.01 5.61x
BenchmarkCodeUnmarshal 19.87 21.76 1.10x
BenchmarkCodeUnmarshal-6 20.08 113.90 5.67x
BenchmarkSkipValue 90.55 89.67 0.99x
BenchmarkSkipValue-6 90.83 87.80 0.97x
benchmark old allocs new allocs delta
BenchmarkIssue10335 4 4 +0.00%
BenchmarkIssue10335-6 4 4 +0.00%
BenchmarkEncoderEncode 1 1 +0.00%
BenchmarkEncoderEncode-6 1 1 +0.00%
benchmark old bytes new bytes delta
BenchmarkIssue10335 320 320 +0.00%
BenchmarkIssue10335-6 320 320 +0.00%
BenchmarkEncoderEncode 8 8 +0.00%
BenchmarkEncoderEncode-6 8 8 +0.00%
updates #18177
Change-Id: Ia4f5bf5ac0afbadb1705ed9f9e1b39dabba67b40
Reviewed-on: https://go-review.googlesource.com/36724
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
JSON decoding performs poorly for unmapped and ignored fields. We noticed better
performance when unmarshalling unused fields. The loss comes mostly from calls
to scanner.error as described at #17914.
benchmark old ns/op new ns/op delta
BenchmarkIssue10335-8 431 408 -5.34%
BenchmarkUnmapped-8 1744 1314 -24.66%
benchmark old allocs new allocs delta
BenchmarkIssue10335-8 4 3 -25.00%
BenchmarkUnmapped-8 18 4 -77.78%
benchmark old bytes new bytes delta
BenchmarkIssue10335-8 320 312 -2.50%
BenchmarkUnmapped-8 568 344 -39.44%
Fixes #17914, improves #10335
Change-Id: I7d4258a94eb287c0fe49e7334795209b90434cd0
Reviewed-on: https://go-review.googlesource.com/33276
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Fixes #18730.
Change-Id: If3ef28e62f7e449d4c8dc1dfd78f7d6f5a87ed26
Reviewed-on: https://go-review.googlesource.com/36478
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Fixes #18086
Change-Id: Idc501dd37893e04a01c6ed9920147d24c0c1fa18
Reviewed-on: https://go-review.googlesource.com/34202
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@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>
|
