summaryrefslogtreecommitdiff
path: root/src/encoding
Commit message (Collapse)AuthorAgeFilesLines
* encoding/json: encode \t as \t instead of \u0009Russ Cox2014-10-272-1/+59
| | | | | | | | | Shorter and easier to read form for a common character. LGTM=bradfitz R=adg, bradfitz CC=golang-codereviews, zimmski https://codereview.appspot.com/162340043
* encoding/csv: for Postgres, unquote empty strings, quote \.Russ Cox2014-10-232-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory both of these lines encode the same three fields: a,,c a,"",c However, Postgres defines that when importing CSV, the unquoted version is treated as NULL (missing), while the quoted version is treated as a string value (empty string). If the middle field is supposed to be an integer value, the first line can be imported (NULL is okay), but the second line cannot (empty string is not). Postgres's import command (COPY FROM) has an option to force the unquoted empty to be interpreted as a string but it does not have an option to force the quoted empty to be interpreted as a NULL. From http://www.postgresql.org/docs/9.0/static/sql-copy.html: The CSV format has no standard way to distinguish a NULL value from an empty string. PostgreSQL's COPY handles this by quoting. A NULL is output as the NULL parameter string and is not quoted, while a non-NULL value matching the NULL parameter string is quoted. For example, with the default settings, a NULL is written as an unquoted empty string, while an empty string data value is written with double quotes (""). Reading values follows similar rules. You can use FORCE_NOT_NULL to prevent NULL input comparisons for specific columns. Therefore printing the unquoted empty is more flexible for imports into Postgres than printing the quoted empty. In addition to making the output more useful with Postgres, not quoting empty strings makes the output smaller and easier to read. It also matches the behavior of Microsoft Excel and Google Drive. Since we are here and making concessions for Postgres, handle this case too (again quoting the Postgres docs): Because backslash is not a special character in the CSV format, \., the end-of-data marker, could also appear as a data value. To avoid any misinterpretation, a \. data value appearing as a lone entry on a line is automatically quoted on output, and on input, if quoted, is not interpreted as the end-of-data marker. If you are loading a file created by another application that has a single unquoted column and might have a value of \., you might need to quote that value in the input file. Fixes issue 7586. LGTM=bradfitz R=bradfitz CC=golang-codereviews https://codereview.appspot.com/164760043
* encoding/gob: add custom decoder buffer for performanceRob Pike2014-10-203-39/+78
| | | | | | | | | | | | | | | | | | | | | | | | | As we did with encoding, provide a trivial byte reader for faster decoding. We can also reduce some of the copying by doing the allocation all at once using a slightly different interface from byte buffers. benchmark old ns/op new ns/op delta BenchmarkEndToEndPipe 13368 12902 -3.49% BenchmarkEndToEndByteBuffer 5969 5642 -5.48% BenchmarkEndToEndSliceByteBuffer 479485 470798 -1.81% BenchmarkEncodeComplex128Slice 92367 92201 -0.18% BenchmarkEncodeFloat64Slice 39990 38960 -2.58% BenchmarkEncodeInt32Slice 30510 27938 -8.43% BenchmarkEncodeStringSlice 33753 33365 -1.15% BenchmarkDecodeComplex128Slice 232278 196704 -15.32% BenchmarkDecodeFloat64Slice 150258 128191 -14.69% BenchmarkDecodeInt32Slice 133806 115748 -13.50% BenchmarkDecodeStringSlice 335117 300534 -10.32% LGTM=rsc R=rsc CC=golang-codereviews https://codereview.appspot.com/154360049
* encoding/gob: fix print format in generated decoder helpersRob Pike2014-10-192-17/+17
| | | | | | | | | Needed a %% to quote a percent in the format. LGTM=adg R=golang-codereviews, adg CC=golang-codereviews https://codereview.appspot.com/156330043
* encoding/gob: use simple append-only buffer for encodingRob Pike2014-10-174-35/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | Bytes buffers have more API and are a little slower. Since appending is a key part of the path in encode, using a faster implementation speeds things up measurably. The couple of positive swings are likely garbage-collection related since memory allocation looks different in the benchmark now. I am not concerned by them. benchmark old ns/op new ns/op delta BenchmarkEndToEndPipe 6620 6388 -3.50% BenchmarkEndToEndByteBuffer 3548 3600 +1.47% BenchmarkEndToEndSliceByteBuffer 336678 367980 +9.30% BenchmarkEncodeComplex128Slice 78199 71297 -8.83% BenchmarkEncodeFloat64Slice 37731 32258 -14.51% BenchmarkEncodeInt32Slice 26780 22977 -14.20% BenchmarkEncodeStringSlice 35882 26492 -26.17% BenchmarkDecodeComplex128Slice 194819 185126 -4.98% BenchmarkDecodeFloat64Slice 120538 120102 -0.36% BenchmarkDecodeInt32Slice 106442 107275 +0.78% BenchmarkDecodeStringSlice 272902 269866 -1.11% LGTM=ruiu R=golang-codereviews, ruiu CC=golang-codereviews https://codereview.appspot.com/160990043
* encoding/gob: custom array/slice decodersRob Pike2014-10-177-29/+874
| | | | | | | | | | | | | | | | | Use go generate to write better loops for decoding arrays, just as we did for encoding. It doesn't help as much, relatively speaking, but it's still noticeable. benchmark old ns/op new ns/op delta BenchmarkDecodeComplex128Slice 202348 184529 -8.81% BenchmarkDecodeFloat64Slice 135800 120979 -10.91% BenchmarkDecodeInt32Slice 121200 105149 -13.24% BenchmarkDecodeStringSlice 288129 278214 -3.44% LGTM=rsc R=rsc CC=golang-codereviews https://codereview.appspot.com/154420044
* encoding/gob: speed up encoding of arrays and slicesRob Pike2014-10-174-3/+708
| | | | | | | | | | | | | | | | | | | | | | | | We borrow a trick from the fmt package and avoid reflection to walk the elements when possible. We could push further with unsafe (and we may) but this is a good start. Decode can benefit similarly; it will be done separately. Use go generate (engen.go) to produce the helper functions (enc_helpers.go). benchmark old ns/op new ns/op delta BenchmarkEndToEndPipe 6593 6482 -1.68% BenchmarkEndToEndByteBuffer 3662 3684 +0.60% BenchmarkEndToEndSliceByteBuffer 350306 351693 +0.40% BenchmarkComplex128Slice 96347 80045 -16.92% BenchmarkInt32Slice 42484 26008 -38.78% BenchmarkFloat64Slice 51143 36265 -29.09% BenchmarkStringSlice 53402 35077 -34.32% LGTM=rsc R=rsc CC=golang-codereviews https://codereview.appspot.com/156310043
* encoding/gob: make encoding structs a little fasterRob Pike2014-10-141-4/+6
| | | | | | | | | | | | | FieldByIndex never returns an invalid Value, so the validity test can be avoided if the field is not indirect. BenchmarkGobEncode 12768642 12424022 -2.70% BenchmarkGobEncode 60.11 61.78 1.03x LGTM=rsc R=rsc CC=golang-codereviews https://codereview.appspot.com/158890045
* encoding/asn1: fix explicitly tagged Times.Adam Langley2014-10-092-2/+50
| | | | | | | | | | | | | | | | | | https://codereview.appspot.com/153770043/ tried to fix the case where a implicitly tagged Time, that happened to have the same tag as GENERALIZEDTIME, shouldn't be parsed as a GENERALIZEDTIME. It did so, mistakenly, by testing whether params.tag != nil. But explicitly tagged values also have a non-nil tag and there the inner tag actually does encode the type of the value. This change instead tests whether the tag class is UNIVERSAL before assuming that the tag contains type information. LGTM=iant R=iant CC=golang-codereviews https://codereview.appspot.com/152380044
* encoding/json: fix handling of null with ,string fieldsRuss Cox2014-10-072-11/+50
| | | | | | | | | Fixes issue 8587. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews, iant, r https://codereview.appspot.com/152270044
* encoding/json: document that embedded interfaces look like non-embedded onesRuss Cox2014-10-061-0/+2
| | | | | | | | | Fixes issue 8386. LGTM=r R=golang-codereviews, r CC=golang-codereviews, iant https://codereview.appspot.com/149570043
* encoding/binary: fix error messageRobert Griesemer2014-10-022-40/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the process, simplified internal sizeOf and dataSize functions. Minor positive impact on performance. Added test case. benchmark old ns/op new ns/op delta BenchmarkReadSlice1000Int32s 14006 14122 +0.83% BenchmarkReadStruct 2508 2447 -2.43% BenchmarkReadInts 921 928 +0.76% BenchmarkWriteInts 2086 2081 -0.24% BenchmarkWriteSlice1000Int32s 13440 13497 +0.42% BenchmarkPutUvarint32 28.5 26.3 -7.72% BenchmarkPutUvarint64 81.3 76.7 -5.66% benchmark old MB/s new MB/s speedup BenchmarkReadSlice1000Int32s 285.58 283.24 0.99x BenchmarkReadStruct 27.90 28.60 1.03x BenchmarkReadInts 32.57 32.31 0.99x BenchmarkWriteInts 14.38 14.41 1.00x BenchmarkWriteSlice1000Int32s 297.60 296.36 1.00x BenchmarkPutUvarint32 140.55 151.92 1.08x BenchmarkPutUvarint64 98.36 104.33 1.06x Fixes issue 6818. LGTM=r R=r CC=golang-codereviews https://codereview.appspot.com/149290045
* encoding/json: don't panic on incorrect map argumentRobert Griesemer2014-10-012-3/+15
| | | | | | | | | Fixes issue 8305. LGTM=rsc R=rsc CC=golang-codereviews https://codereview.appspot.com/145680044
* encoding/binary: slightly better documentationRobert Griesemer2014-10-011-3/+4
| | | | | | | | | Fixes issue 7306. LGTM=r R=r CC=golang-codereviews https://codereview.appspot.com/153820044
* encoding/asn1: fix unmarshaling of implicitly tagged UTF-8 strings.Adam Langley2014-09-302-4/+13
| | | | | | | | | Fixes issue 8541. LGTM=rsc R=rsc CC=golang-codereviews https://codereview.appspot.com/153770043
* encoding/gob: fix 386 buildRob Pike2014-09-251-9/+6
| | | | | | | LGTM=ruiu R=golang-codereviews, ruiu CC=golang-codereviews https://codereview.appspot.com/146320043
* encoding/gob: error rather than panic when decoding enormous slicesRob Pike2014-09-253-4/+39
| | | | | | | | | Fixes issue 8084. LGTM=ruiu R=golang-codereviews, ruiu CC=golang-codereviews https://codereview.appspot.com/142710043
* encoding/gob: speedup encodingDmitriy Vyukov2014-09-183-66/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace typeLock with copy-on-write map using atomic.Value. benchmark old ns/op new ns/op delta BenchmarkEndToEndPipe 7722 7709 -0.17% BenchmarkEndToEndPipe-2 5114 4344 -15.06% BenchmarkEndToEndPipe-4 3192 2429 -23.90% BenchmarkEndToEndPipe-8 1833 1438 -21.55% BenchmarkEndToEndPipe-16 1332 983 -26.20% BenchmarkEndToEndPipe-32 1444 675 -53.25% BenchmarkEndToEndByteBuffer 6474 6019 -7.03% BenchmarkEndToEndByteBuffer-2 4280 2810 -34.35% BenchmarkEndToEndByteBuffer-4 2264 1774 -21.64% BenchmarkEndToEndByteBuffer-8 1275 979 -23.22% BenchmarkEndToEndByteBuffer-16 1257 753 -40.10% BenchmarkEndToEndByteBuffer-32 1342 644 -52.01% BenchmarkEndToEndArrayByteBuffer 727725 671349 -7.75% BenchmarkEndToEndArrayByteBuffer-2 394079 320473 -18.68% BenchmarkEndToEndArrayByteBuffer-4 211785 178175 -15.87% BenchmarkEndToEndArrayByteBuffer-8 141003 118857 -15.71% BenchmarkEndToEndArrayByteBuffer-16 139249 86367 -37.98% BenchmarkEndToEndArrayByteBuffer-32 144128 73454 -49.04% LGTM=r R=golang-codereviews, r CC=golang-codereviews https://codereview.appspot.com/147720043
* build: move package sources from src/pkg to srcRuss Cox2014-09-0870-0/+29427
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.