[hknmtt]

i don't see any issue here. same behavior can be achieved with slices: foo := make([]int, 0, 1000) for { for k := range bar { foo = append(foo, k) } foo = foo[:0] }

the slice will grow as much as the largest dataset. map will be the same. you need to let go of it to be GCd and create a new one.

[olliej]

The point is that you can remove the entries from the map, and the map won't ever shrink. If you're using large value type in the map[1], the map's dead storage will be large - by a functionally unbound amount. Most sane collection libraries shrink their backing store after some sufficiently large portion becomes dead.

[1] I would argue a general purpose hash table/map should really switch to using a hash code=>index mapping automatically if the value type size is sufficiently large.

[morelisp]

> Most sane collection libraries shrink their backing store after some sufficiently large portion becomes dead.

If you exclude Java, and C++ and C# I think, stdlibs from being sane, sure.

[olliej]

womp womp, you are indeed correct. I'd swear that Java and .NET's did, but I assume that's bad memory at fault :(

I will say though that I don't consider C++'s various maps to be sane :D

[rob74]

The map will shrink, just not by as much as you might expect. You could also argue that they have picked a pathological case for their example because they use 128 byte entries ("If a key or a value is over 128 bytes, Go won’t store it directly in the map bucket. Instead, Go stores a pointer to reference the key or the value" - which probably leads to less memory consumption).