-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
runtime: reuse map string key instead of allocating #55930
Comments
One way to implement this is to have a variation of |
Doesn't the allocation happen during the []byte->string conversion instead? |
I do not believe that is what is happening since switching to map access results in zero allocations: func Benchmark(b *testing.B) {
m := map[string]int{}
k := []byte("hello, world")
b.ReportAllocs()
for i := 0; i < b.N; i++ {
sink += m[string(k)]
}
} prints:
|
There is a special case in the compiler for That said, where does this come up? You can always do
That saves an allocation at the cost of a map lookup. |
@randall77. Unfortunately, the suggested workaround doesn't work if you want to update the value for an entry at the same key, which is the situation that I'm running into. |
I see, you're getting bitten by the key overwrite we decided was correct in #11088. |
In #11088 (comment):
Personally, I've never seen that pattern ever before. Usually, if someone were concerned about string keys pinning a large amount of memory, they do the equivalent of On the other hand, I'd argue that this issue would benefit patterns that are more common:
|
Also, the |
@dsnet Could we do something like this:
|
Yeah, but I see in your example that appendToLower is controlled by us, so it should still be safe, no 🤔 |
It appends into a buffer that is allocated on the stack (backed by the |
So
And that's count as allocating:
My original example works because |
I'm not sure I understand the benefit anymore. This seems to defeat the point of the optimization that |
Yeah, I mean my approach above won't work, it works in original example because the |
Consider the following benchmark:
This currently prints:
I expect this to not allocate since it is reusing the same map entry every time.
The very first
mapassign
will need to allocate the string on heap, but subsequent operations should not need to.This is related to #45045, which made this optimization harder.
\cc @randall77 @cuonglm
The text was updated successfully, but these errors were encountered: