aboutsummaryrefslogtreecommitdiff
path: root/src/encoding/xml
diff options
context:
space:
mode:
authorKeith Randall <khr@golang.org>2016-10-11 08:36:38 -0700
committerKeith Randall <khr@golang.org>2016-10-12 20:41:23 +0000
commit442de98c14d49bf306ab880e9f9c898ca0ae7c19 (patch)
treeecad31c2e5b001801ae5d0afe792f8587532ae67 /src/encoding/xml
parent55ef67f2f85c51d415a030ae144a0b3301a097bd (diff)
downloadgo-442de98c14d49bf306ab880e9f9c898ca0ae7c19.tar.xz
cmd/compile,runtime: redo how map assignments work
To compile: m[k] = v instead of: mapassign(maptype, m, &k, &v), do do: *mapassign(maptype, m, &k) = v mapassign returns a pointer to the value slot in the map. It is just like mapaccess except that it will allocate a new slot if k is not already present in the map. This makes map accesses faster but potentially larger (codewise). It is faster because the write into the map is done when the compiler knows the concrete type, so it can be done with a few store instructions instead of calling typedmemmove. We also potentially avoid stack temporaries to hold v. The code can be larger when the map has pointers in its value type, since there is a write barrier call in addition to the mapassign call. That makes the code at the callsite a bit bigger (go binary is 0.3% bigger). This CL is in preparation for doing operations like m[k] += v with only a single runtime call. That will roughly double the speed of such operations. Update #17133 Update #5147 Change-Id: Ia435f032090a2ed905dac9234e693972fe8c2dc5 Reviewed-on: https://go-review.googlesource.com/30815 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
Diffstat (limited to 'src/encoding/xml')
0 files changed, 0 insertions, 0 deletions