Also remove the introduction, which says what the rest of the
page says anyway.

Fixes #5182.

R=golang-dev, kamil.kisiel, r
CC=golang-dev
https://golang.org/cl/8281044

This changes the map lookup behavior for string maps with 2-8 keys.

There was already previously a fastpath for 0 items and 1 item.

Now, if a string-keyed map has <= 8 items, first check all the
keys for length first. If only one has the right length, then
just check it for equality and avoid hashing altogether. Once
the map has more than 8 items, always hash like normal.

I don't know why some of the other non-string map benchmarks
got faster. This was with benchtime=2s, multiple times. I haven't
anything else getting slower, though.

benchmark                             old ns/op    new ns/op    delta
BenchmarkHashStringSpeed                     37           34   -8.20%
BenchmarkHashInt32Speed                      32           29  -10.67%
BenchmarkHashInt64Speed                      31           27  -12.82%
BenchmarkHashStringArraySpeed               105           99   -5.43%
BenchmarkMegMap                          274206       255153   -6.95%
BenchmarkMegOneMap                           27           23  -14.80%
BenchmarkMegEqMap                        148332       116089  -21.74%
BenchmarkMegEmptyMap                          4            3  -12.72%
BenchmarkSmallStrMap                         22           22   -0.89%
BenchmarkMapStringKeysEight_32               42           23  -43.71%
BenchmarkMapStringKeysEight_64               55           23  -56.96%
BenchmarkMapStringKeysEight_1M           279688           24  -99.99%
BenchmarkIntMap                              16           15  -10.18%
BenchmarkRepeatedLookupStrMapKey32           40           37   -8.15%
BenchmarkRepeatedLookupStrMapKey1M       287918       272980   -5.19%
BenchmarkNewEmptyMap                        156          130  -16.67%

R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/7641057

Also, move an existing benchmark from map_test.go to
mapspeed_test.go.

R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/8294043

Update #4553.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8293043

It was unnecessarily cloning and then mutating a map that had
a very short lifetime (just that function).

No new tests, because they were added in revision 833bf2ef1527
(TestHeaderToWire). The benchmarks below are from the earlier
commit, revision 52e3407d.

I noticed this inefficiency when reviewing a change Peter Buhr
is looking into, which will also use these benchmarks.

benchmark                         old ns/op    new ns/op    delta
BenchmarkServerHandlerTypeLen         12547        12325   -1.77%
BenchmarkServerHandlerNoLen           12466        11167  -10.42%
BenchmarkServerHandlerNoType          12699        11800   -7.08%
BenchmarkServerHandlerNoHeader        11901         9210  -22.61%

benchmark                        old allocs   new allocs    delta
BenchmarkServerHandlerTypeLen            21           20   -4.76%
BenchmarkServerHandlerNoLen              20           18  -10.00%
BenchmarkServerHandlerNoType             20           18  -10.00%
BenchmarkServerHandlerNoHeader           17           13  -23.53%

benchmark                         old bytes    new bytes    delta
BenchmarkServerHandlerTypeLen          1930         1913   -0.88%
BenchmarkServerHandlerNoLen            1912         1879   -1.73%
BenchmarkServerHandlerNoType           1912         1878   -1.78%
BenchmarkServerHandlerNoHeader         1491         1086  -27.16%

R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/8268046

(amd64)
benchmark           old ns/op    new ns/op    delta
BenchmarkEqual0            16            6  -63.15%
BenchmarkEqual9            22            7  -65.37%
BenchmarkEqual32           36            9  -74.91%
BenchmarkEqual4K         2187          120  -94.51%

benchmark            old MB/s     new MB/s  speedup
BenchmarkEqual9        392.22      1134.38    2.89x
BenchmarkEqual32       866.72      3457.39    3.99x
BenchmarkEqual4K      1872.73     33998.87   18.15x

(386)
benchmark           old ns/op    new ns/op    delta
BenchmarkEqual0            16            5  -63.85%
BenchmarkEqual9            22            7  -67.84%
BenchmarkEqual32           34           12  -64.94%
BenchmarkEqual4K         2196          113  -94.85%

benchmark            old MB/s     new MB/s  speedup
BenchmarkEqual9        405.81      1260.18    3.11x
BenchmarkEqual32       919.55      2631.21    2.86x
BenchmarkEqual4K      1864.85     36072.54   19.34x

Update #3751

R=bradfitz, r, khr, dave, remyoudompheng, fullung, minux.ma, ality
CC=golang-dev
https://golang.org/cl/8056043

For all the Content-Type & Content-Length cases.

R=golang-dev, pabuhr
CC=golang-dev
https://golang.org/cl/8280046

A package file may begin as either "package foo" or
"package foo safe". The latter is relevant when using -u.
https://golang.org/cl/6903059 resulted in the distinction
being dropped when a package was read for the second or later time.
This CL records whether that "safe" tag was present,
and includes it in the dummy statement generated for the lexer.

R=golang-dev, r, minux.ma, daniel.morsing, iant
CC=golang-dev
https://golang.org/cl/8255044

The expected precision setting for the x87 on Win32 is 53-bit
but MinGW resets the floating point unit to 64-bit.  Win32
object code generally expects values to be rounded to double,
not double extended, precision.

R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/8175044

Per discussions on golang-nuts and golang-dev:
"Some concerns with DialOpt"
https://groups.google.com/d/msg/golang-nuts/Hfh9aqhXyUw/W3uYi8lOdKcJ
https://groups.google.com/d/msg/golang-dev/37omSQeWv4Y/KASGIfPpXh0J

R=golang-dev, google, r
CC=golang-dev
https://golang.org/cl/8274043

Fixes #5059.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8284043

Fixes #5181.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8277043

R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/8276043

Fixes #5186.

R=bradfitz
CC=golang-dev
https://golang.org/cl/8267044

s/ordering/less/g

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8267043

Demonstrates one way to sort a slice of structs according
to different sort criteria, done in sequence.

One possible answer to a question that comes up often.

R=golang-dev, gri, bradfitz, adg, adg, rogpeppe
CC=golang-dev
https://golang.org/cl/8182044

From a discussion on golang-nuts.

R=golang-dev, dsymonds, nigeltao, coocood, adg
CC=golang-dev
https://golang.org/cl/8251043

(x<<1 | x>>31).

Fixes #5084.

On the SHA3 benchmark proposals at
https://golang.org/cl/7760044/

benchmark                       old ns/op    new ns/op    delta
BenchmarkPermutationFunction         1288         1191   -7.53%
BenchmarkSingleByteWrite             5795         5811   +0.28%
BenchmarkBlockWrite512                178          179   +0.56%
BenchmarkBlockWrite384                230          233   +1.30%
BenchmarkBlockWrite256                282          286   +1.42%
BenchmarkBlockWrite224                301          306   +1.66%
BenchmarkBulkHashSHA3_512          326885       304548   -6.83%
BenchmarkBulkHashSHA3_384          234839       220074   -6.29%
BenchmarkBulkHashSHA3_256          186969       175790   -5.98%
BenchmarkBulkHashSHA3_224          178133       167489   -5.98%

For a function like

func g() {
        x = a[3]<<20 | a[3]>>12
}

the asm goes from

0006 (main.go:10) TEXT    g+0(SB),$0-0
0007 (main.go:10) MOVL    a+12(SB),BP
0008 (main.go:10) LOCALS  ,$0
0009 (main.go:11) MOVL    BP,BX
0010 (main.go:11) SHLL    $20,BX
0011 (main.go:11) SHRL    $12,BP
0012 (main.go:11) ORL     BP,BX
0013 (main.go:11) MOVL    BX,x+0(SB)
0014 (main.go:12) RET     ,

to

0006 (main.go:10) TEXT    g+0(SB),$0-0
0007 (main.go:10) LOCALS  ,$0
0008 (main.go:11) MOVL    a+12(SB),BX
0009 (main.go:11) ROLL    $20,BX
0010 (main.go:11) MOVL    BX,x+0(SB)
0011 (main.go:12) RET     ,

R=rsc, iant, remyoudompheng
CC=golang-dev, jcb
https://golang.org/cl/7944043

Mention support for NetBSD, OpenBSD, and cgo for linux/arm.

R=golang-dev, dvyukov, r, minux.ma, adg, bradfitz, adg
CC=golang-dev
https://golang.org/cl/8152043

Doing grow work on reads is not multithreaded safe.
Changed code to do grow work only on inserts & deletes.

This is a short-term fix, eventually we'll want to do
grow work in parallel to recover the space of the old
table.

Fixes #5120.

R=bradfitz, khr
CC=golang-dev
https://golang.org/cl/8242043

Fixes #5176.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8118046

The text is printed only if the test fails or -test.v is set.
Document this behavior in the testing package and 'go help test'.
Also put a 'go install' into mkdoc.sh so I don't get tricked by the
process of updating the documentation ever again.

Fixes #5174.

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/8118047

Fixes #5024.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8222045

Fixes #4730.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8229043

use MOVW.NE instead of BEQ and MOVW.

R=golang-dev, dave, rsc, daniel.morsing
CC=golang-dev
https://golang.org/cl/7718043

Eliminates a format consistency warning.

R=gloang-dev, r
CC=golang-dev
https://golang.org/cl/8217043

Permits specifying the linker to use, and trailing flags to
pass to that linker, when linking in external mode.  External
mode linking is used when building a package that uses cgo, as
described in the cgo docs.

Also document -linkmode and -tmpdir.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8225043

Reusing it when multiple comparisons occurred in the same
function call led to bad overwriting.

Fixes #5162.

R=golang-dev, daniel.morsing
CC=golang-dev
https://golang.org/cl/8174047

Currently crashes, so disabled.

Update #5179

R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/8222044

If a package was listed as a dependency from multiple places, it
could have been cleaned repeatedly.

R=golang-dev, dave, rsc, seed, bradfitz
CC=golang-dev, minux.ma
https://golang.org/cl/7482043

Fixes #5149.

R=golang-dev, dave, minux.ma
CC=golang-dev
https://golang.org/cl/8136043

<stdint.h> does not seem to be needed.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8178044

Closes the API documentation gap between platforms.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8063044

Closes the API documentation gap between platforms.
Also makes the code textual representation same between platforms.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8148043

Closes the API documentation gap between platforms.
Also makes the code textual representation same between platforms.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8147043

Closes the API documentation gap between platforms.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8143044

Since we can't properly handle anything except 100, treat all
1xx informational responses as sketchy and don't reuse the
connection for future requests.

The only other 1xx response code currently in use in the wild
is WebSockets' use of "101 Switching Protocols", but our
code.google.com/p/go.net/websockets doesn't use Client or
Transport: it uses ReadResponse directly, so is unaffected by
this CL.  (and its tests still pass)

So this CL is entirely just future-proofing paranoia.
Also: the Internet is weird.

Update #2184
Update #3665

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/8208043

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8201043

Whoops. I'm surprised it even worked before. (Need two pipes,
not one.)

Also, remove the whole pipe registration business, since it
wasn't even required in the previous version. (I'd later fixed
it at the end of send100Response, but forgot to delete it)

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8191044

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8198043