3 ms·
Thanks! That clarifies a few things. Too bad this isn't covered in the blog post which was specifically about how Go implements maps efficiently. Here are two i
by blixt 8y ago
Thanks! That clarifies a few things. Too bad this isn't covered in the blog post which was specifically about how Go implements maps efficiently. Here are two interesting things the post doesn't cover:
1) How the insert works and why it's this way instead of any other;
2) Apparently the runtime has specialized implementations to insert values for some key types (string in this case), which implies it does in fact have multiple implementations of the "same" code.
Edit: I'm also curious how plain Go code can assign a value directly to an unsafe pointer without expressing the type? Or is that made unnecessary because the compiler rewrites the `myMap["key"] = value` step and has free reign to output unsafe, untyped Go code that isn't normally valid?
- benmmurphy 8y agoyeah. my guess is the compiler just outputs its intermediate format when it sees map assignment and can just do whatever it wants. for reference you can play around with this by doing: go build test.go go tool objdump ./test then search for test.go in the output and you should be able to find the go 'assembly' for your functions. also, if you use a big enough struct type then go will call into a memcpy() style routine to do the assignment. test.go:32 0x108d791 488d15d7170300 LEAQ go.string.*+255(SB), DX test.go:32 0x108d798 4889542410 MOVQ DX, 0x10(SP) test.go:32 0x108d79d 48c744241803000000 MOVQ $0x3, 0x18(SP) test.go:32 0x108d7a6 e835c2f7ff CALL runtime.mapassign_faststr(SB) test.go:32 0x108d7ab 488b7c2420 MOVQ 0x20(SP), DI test.go:32 0x108d7b0 488d742430 LEAQ 0x30(SP), SI test.go:32 0x108d7b5 48896c24f0 MOVQ BP, -0x10(SP) test.go:32 0x108d7ba 488d6c24f0 LEAQ -0x10(SP), BP test.go:32 0x108d7bf e83807fcff CALL 0x104defc 0x104defc for me looks like it duffcopy from this file: https://golang.org/src/runtime/duff_amd64.s https://golang.org/src/runtime/duff_amd64.s