cmd/compile: optimizing multiple accesses to same key in map

[rasky]

I was reviewing some code for performance issues, and the profile pointed me to a function that was accessing the same map element multiple times like this:

data[key].Foo = 1
data[key].Bar.Baz += 4
[...]

The profile showed many calls to runtime.mapaccess1_fast32. I was wondering if it would be legal for the compiler to optimize this straight code to do only one map access, and then of course if it's worth doing it or not.

[randall77]

Yes, this would be awesome. I've been pondering it. I think we just want to recognize redundant calls and use the same return value from mapaccess* (the pointer to the value) again.

We probably need a mapaccess variant, "lookup key, plus allocate key->0 if not found" method.

Also good for m[x] += 5.

See #5147.

[dgryski]

It would be nice if this could optimize the one place I've been able to beat the built-in map with a custom implementation: lookup-and-insert-if-not-present. With strings especially as this can require hashing twice.

[bradfitz]

Damian, I think I have an existing bug open for that.

[cespare]

It's #5147 that @randall77 linked above.

[dgryski]

Oops, thanks. Sorry for the noise. Subscribed to the original.

[gopherbot]

CL https://golang.org/cl/30815 mentions this issue.

[rsc]

@randall77, is the second half of this going to land in Go 1.8, or should we move this issue to Go 1.9?

[randall77]

Not sure yet. Magic 8 ball says "looking iffy". Leave it here for now.