aboutsummaryrefslogtreecommitdiff
path: root/src/encoding/json
AgeCommit message (Collapse)Author
2018-10-06encoding/json: use isSpace in stateEndTopGabriel Aszalos
This change makes stateEndTop use isSpace instead of specifically recreating the same functionality. Change-Id: I81f8f51682e46e7f8e2b9fed423a968457200625 Reviewed-on: https://go-review.googlesource.com/c/121797 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-09-12encoding/json: use panics for phase errorsDaniel Martí
Having these panic-like errors used to be ok, since they were used in the internal decoder state instead of passed around via return parameters. Recently, the decoder was rewritten to use explicit error returns instead. This error is a terrible fit for error returns; a handful of functions must return an error because of it, and their callers must check for an error that should never happen. This is precisely what panics are for, so use them. The test coverage of the package goes up from 91.3% to 91.6%, and performance is unaffected. We can also get rid of some unnecessary verbosity in the code. name old time/op new time/op delta CodeDecoder-4 27.5ms ± 1% 27.5ms ± 1% ~ (p=0.937 n=6+6) Change-Id: I01033b3f5b7c0cf0985082fa272754f96bf6353c Reviewed-on: https://go-review.googlesource.com/134835 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-12encoding/json: more tests to cover decoding edge casesDaniel Martí
The overall coverage of the json package goes up from 90.8% to 91.3%. While at it, apply two minor code simplifications found while inspecting the HTML coverage report. Change-Id: I0fba968afeedc813b1385e4bde72d93b878854d7 Reviewed-on: https://go-review.googlesource.com/134735 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-09-06encoding/json: recover saved error context when unmarshallingIan Davis
Fixes: #27464 Change-Id: I270c56fd0d5ae8787a1293029aff3072f4f52f33 Reviewed-on: https://go-review.googlesource.com/132955 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-08-28encoding/json: fix UnmarshalTypeError without field and struct valuesTaesu Pyo
Fixes #26444 Fixes #27275 Change-Id: I9e8cbff79f7643ca8964c572c1a98172b6831730 GitHub-Last-Rev: 7eea2158b67ccab34b45a21e8f4289c36de02d93 GitHub-Pull-Request: golang/go#26719 Reviewed-on: https://go-review.googlesource.com/126897 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-08-26encoding/json: fix handling of nil anonymous structsDaniel Martí
Given the following types: type S2 struct{ Field string } type S struct{ *S2 } Marshalling a value of type T1 should result in "{}", as there's no way to access any value of T2.Field. This is how Go 1.10 and earlier versions behave. However, in the recent refactor golang.org/cl/125417 I broke this logic. When the encoder found an anonymous struct pointer field that was nil, it no longer skipped the embedded fields underneath it. This can be seen in the added test: --- FAIL: TestAnonymousFields/EmbeddedFieldBehindNilPointer (0.00s) encode_test.go:430: Marshal() = "{\"Field\":\"\\u003c*json.S2 Value\\u003e\"}", want "{}" The human error was a misplaced label, meaning we weren't actually skipping the right loop iteration. Fix that. Change-Id: Iba8a4a77d358dac73dcba4018498fe4f81afa263 Reviewed-on: https://go-review.googlesource.com/131376 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-08-26encoding/json: get rid of the stream_test.go TODOsDaniel Martí
TestRawMessage now passes without the need for the RawMessage field to be a pointer. The TODO dates all the way back to 2010, so I presume the issue has since been fixed. TestNullRawMessage tested the decoding of a JSON null into a *RawMessage. The existing behavior was correct, but for the sake of completeness a non-pointer RawMessage field has been added too. The non-pointer field behaves differently, as one can read in the docs: To unmarshal JSON into a value implementing the Unmarshaler interface, Unmarshal calls that value's UnmarshalJSON method, including when the input is a JSON null. Change-Id: Iabaed75d4ed10ea427d135ee1b80c6e6b83b2e6e Reviewed-on: https://go-review.googlesource.com/131377 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-08-25encoding/json: remove a branch in the structEncoder loopDaniel Martí
Encoders like map and array can use the much cheaper "i > 0" check to see if we're not writing the first element. However, since struct fields support omitempty, we need to keep track of that separately. This is much more expensive - after calling the field encoder itself, and retrieving the field via reflection, this branch was the third most expensive piece of this field loop. Instead, hoist the branch logic outside of the loop. The code doesn't get much more complex, since we just delay the writing of each byte until the next iteration. Yet the performance improvement is noticeable, even when the struct types in CodeEncoder only have 2 and 7 fields, respectively. name old time/op new time/op delta CodeEncoder-4 5.39ms ± 0% 5.31ms ± 0% -1.37% (p=0.010 n=4+6) name old speed new speed delta CodeEncoder-4 360MB/s ± 0% 365MB/s ± 0% +1.39% (p=0.010 n=4+6) Updates #5683. Change-Id: I2662cf459e0dfd68e56fa52bc898a417e84266c2 Reviewed-on: https://go-review.googlesource.com/131401 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-08-25encoding/json: avoid some more pointer receiversDaniel Martí
A few encoder struct types, such as map and slice, only encapsulate other prepared encoder funcs. Using pointer receivers has no advantage, and makes calling these methods slightly more expensive. Not a huge performance win, but certainly an easy one. The struct types used in the benchmark below contain one slice field and one pointer field. name old time/op new time/op delta CodeEncoder-4 5.48ms ± 0% 5.39ms ± 0% -1.66% (p=0.010 n=6+4) name old speed new speed delta CodeEncoder-4 354MB/s ± 0% 360MB/s ± 0% +1.69% (p=0.010 n=6+4) Updates #5683. Change-Id: I9f78dbe07fcc6fbf19a6d96c22f5d6970db9eca4 Reviewed-on: https://go-review.googlesource.com/131400 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-08-22encoding/json: simplify some pieces of the encoderDaniel Martí
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>
2018-08-22encoding/json: inline fieldByIndexDaniel Martí
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>
2018-08-22encoding/json: simplify the structEncoder typeDaniel Martí
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>
2018-08-21encoding/json: various minor decoder speed-upsDaniel Martí
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>
2018-08-21encoding/json: defer error context work until necessaryDaniel Martí
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>
2018-08-21encoding/json: remove alloc when encoding short byte slicesDaniel Martí
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>
2018-08-21encoding/json: encode struct field names ahead of timeDaniel Martí
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-08-21encoding/json: call reflect.TypeOf with nil pointers rather than allocatingTim Cooper
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>
2018-08-21encoding/json: eliminate superfluous space in Decoder.Token error messagesPhilip Børgesen
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>
2018-06-01all: update comment URLs from HTTP to HTTPS, where possibleTim Cooper
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>
2018-04-20encoding/json: remove unnecessary if conditionstengufromsky
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>
2018-04-17encoding/json: simplify dominantFieldMichael Fraenkel
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>
2018-04-13encoding/json: make use of encodeStatePool in MarshalJeremy Jackins
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>
2018-04-09encoding/json: remove unnecessary else conditionsbontequero
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>
2018-04-04go/printer, gofmt: tuned table alignment for better resultsRobert Griesemer
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
2018-03-03encoding/json: apply conventional error handling in decoderPascal S. de Kloe
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-03encoding/json: use sync.Map for field cacheJoe Tsai
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>
2018-03-01encoding/json: read ahead after value consumptionPascal S. de Kloe
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>
2018-03-01encoding/json: avoid assuming side-effect free reflect.Value.Addr().Elem()Joe Tsai
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>
2018-02-14encoding/json: make error capture logic in recover more type safeJoe Tsai
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>
2017-12-06encoding/json: error when trying to set an embedded pointer to unexported ↵Joe Tsai
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>
2017-11-27encoding/json: remove the word "text" in "JSON text" from package docs.rajender
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>
2017-11-27encoding/json: update RFC numberrajender
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>
2017-11-22encoding/json: reduce allocations by Decoder for \uXXXXMichael Schurter
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>
2017-11-13encoding/json: always ignore embedded pointers to unexported struct typesJoe Tsai
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>
2017-11-08encoding/json: permit encoding uintptr as a stringIan Lance Taylor
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>
2017-11-04all: change github.com issue links to golang.orgLeigh McCulloch
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>
2017-10-31encoding/json: Include the offset of a SyntaxErrorMichael Fraenkel
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>
2017-10-31encoding/json: disallow unknown fields in DecoderIvan Bertona
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>
2017-10-11encoding/json: use Deprecated markersJoe Tsai
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>
2017-10-05all: revert "all: prefer strings.IndexByte over strings.Index"Marvin Stenger
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>
2017-09-27encoding/json: remove superfluous commentMarvin Stenger
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>
2017-09-27all: prefer bytes.IndexByte over bytes.IndexMarvin Stenger
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>
2017-09-25all: prefer strings.IndexByte over strings.IndexMarvin Stenger
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>
2017-09-23encoding/json: cleanup detection of unexported embedded fieldsJoe Tsai
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>
2017-09-12encoding/json: update documentation for MarshalIndenttbunyk
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>
2017-08-28all: remove some unused result paramsDaniel Martí
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>
2017-08-26all: remove some double spaces from commentsDaniel Martí
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>
2017-08-08encoding/json: de-indent raw strings in remaining examplesDmitri Shuralyov
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>
2017-07-22encoding/json: ignore embedded fields of pointers to unexported non-structsJoe Tsai
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>
2017-07-15encoding/json: fix indentation in Decode stream exampleIccha Sethi
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>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 12:42:54 +0000