Hi, I noticed the GC fix which avoids scanning maps if both key and value are not pointer types. [1] and see it used [2] and discussed [3]
So... Initially, I figured this was not worth thinking too much about, but then I came to thing about the relatively common use case where your map value is an object you get from a sync.Pool In other words... you already have exempted the *Objects from normal garbage collection probably already have some structure in place for knowing when to call pool.Put() to return the objects. I would seem silly to scan an entire map which only contains Pool issued pointers. So, I tried to measure GC time the same way as [3] but now with a map[int]uintptr holding pointers to the objects I got from sync.Pool and it seems there are still significant GC gains to be had. Of course... it requires that you handle any collisions in hashing the string key to an int yourself, but wrt. the value I curious if anyone can see issued with just storing a uintptr instead of the pointer for sync.Pool managed objects. - (provided you remember to call pool.Put() before loosing the map reference or doing delete() on a key.) m[key] = uintptr(unsafe.Pointer(pool.Get().(*Object))) /Peter 1: https://go-review.googlesource.com/c/go/+/3288 2: https://github.com/allegro/bigcache/blob/master/shard.go#L14 3: https://www.komu.engineer/blogs/go-gc-maps -- 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. For more options, visit https://groups.google.com/d/optout.
