4 ms·
This all looks like reasonable implementation behavior which will give optimal runtime performance in most "common" cases. If one really wants or needs a map th
by eschneider 4y ago
This all looks like reasonable implementation behavior which will give optimal runtime performance in most "common" cases. If one really wants or needs a map that'll free memory as it shrinks (and sure, for some folks, that'd be super useful) one's always free to just implement your own.
- eptcyka 4y agoGo doesn't really allow you to create a hashmap with the same generic possibilities as the built in one.
- ironick09 4y agoWhy is it? Or rather what limitations are there to enforced by go compiler that won’t allow someone to implement their own hash map that can free memory with the same generic possibilities, even with the recent introduction of generics?
- eptcyka 4y agoSeems like I was wrong about my assumptions about Go's generics - it does seem like they're specialized at build time and it is possible to operate over generic values rather than fat pointers. So it is possible to implement a fully featured hash map without extra pointer hopping now. I stand corrected.
- jimbokun 4y agoIs that still true with the support Go added for generics?
- morelisp 4y agoYou probably won't be able to match the built-in's performance without a similarly large surface area of unsafe usage. And Go's maintainers won't maintain your unsafe code for you as they do the default, nor consider the impact of other language changes on your micro-optimizations. https://github.com/golang/go/blob/master/src/runtime/map.go https://github.com/golang/go/blob/master/src/runtime/map.go You also won't have `for k, v := range` iteration, but that is also likely being addressed within the next few versions. But - no, there's not really any major ergonomic issues to basic lookups given generics these days.
- deleted 4y ago[deleted]