runtime: optimize for special case where two-return-value map access discards the value #12776
Labels
Comments
|
It's already optimized for in src/cmd/compile/internal/gc/walk.go: // don't generate a = *var if a is _
if !isblank(a) {
var_ := temp(Ptrto(t.Type))
var_.Typecheck = 1
n.List.N = var_
walkexpr(&n, init)
*init = list(*init, n)
n = Nod(OAS, a, Nod(OIND, var_, nil))
}And the "pointer arithmetic necessary to find that value" has already been done at the point it's determined whether it's in the map or not. There is perhaps an addition or multiplication that could be removed, but it's so minor compared to the work already done up to that point. And I imagine plumbing down a "skip this one addition and multiple" would be heavier than just doing it. |
|
mapaccess with two return values will call runtime.mapaccess2
and its "fast" alternatives, they don't actually copy the value
out, they return an unsafe.Pointer for the value, and as Brad
mentions, the compiler won't copy the object if it's assigned
to _.
Adding another map access routine to runtime that only returns
the ok value won't save much because once the entry is found,
it's trivial to return it's address. And not to mention the code
duplication if we optimize for this case.
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
A pattern that I'm coming up on reasonably frequently in my code is the following:
It seems to me like there would be some (albeit small) gains to be had in the compiler detecting this particular case of discarding the value result of map-lookup in favor of only returning the boolean, and avoid doing the pointer arithmetic necessary to find that value.
The text was updated successfully, but these errors were encountered: