PS: I was curious, and https://play.golang.org/p/oLnRnuE3rQ_W (awkwardly)
does seem to indicate that the current reflect map iterator indeed
allocates on every iteration. Because the number of allocations goes up if
the number of keys goes up. Of course I can't compare it to my suggested
alternative reflect API without implementing that :)
On Mon, Mar 8, 2021 at 10:26 PM Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> Hi,
>
> On Mon, Mar 8, 2021 at 10:07 PM Ian Lance Taylor <i...@golang.org> wrote:
>
>> > 2. When I need to iterate map.
>> > Using standard reflect package there is no way to iterate
>> map[string]int without allocation of string header and int for every
>> key-value pair. When
>> > key or values is struct, things become worse.
>>
>> That is how the language works also. Map keys and values are not
>> addressable.
>
>
> I'm not sure I fully understand the issue, but
> for k, v := range m
> only needs to allocate storage for k/v *once*. AIUI, `MapIter.Key` and
> `MapIter.Value` need to allocate on every iteration (or at least that's how
> I read the comment by Yura). However, if MapIter's methods would have
> signatures
> Key(v Value)
> Value(v Value)
> we could create *one* value of the key/value type. The methods would then
> call `v.Set` to copy the non-addressable internal value into the
> addressable iteration variables. This would be closer to the for loop -
> we'd still (maybe) need to heap-allocate the iteration variables, but that
> would only have to happen once per loop, not once per iteration.
>
> Disclaimer: I haven't verified if `MapIter.{Key,Value}` actually do
> allocate on every call, that's just how I read the comment. It's possible
> escape analysis is already clever enough for this (though I don't know how
> it would be).
>
>
>> Keeping an address for them is very deeply unsafe, and
>> could break irretrievably with future changes to the garbage
>> collector. Or, to put it another way, supporting this functionality
>> imposes limitations on the garbage collector that I don't think we
>> want to impose. I'm not sure what we can do here. Go's map type
>> intentionally does not give programs complete control over memory.
>
>
>> It's possible that generics will address some of these use cases.
>>
>> Ian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWzLyD0gn9r25M6HTGoXgUJEwXz-y2qVX4C4%3DGXp8mouQ%40mail.gmail.com
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfG91AD-gSQ5eVw4%3DFKdVEd76%3Dgz5CHdr5w5geNeTJ1T9Q%40mail.gmail.com.
