proposal: runtime: add way to clear and reuse a map's working storage

[AsterDY]

go/src/runtime/map.go

Line 303 in db8142f

func makemap(t *maptype, hint int, h *hmap) *hmap {

I see runtime.makemap() gives a way to reuse old hmap's buckets, but it is only used when mallocating small maps on stack at present. Why not open this shortcut to users for memory reusing? Actually I only need exporting runtime.makemap() and runtime.clearmap() to achieve this goal:

func resetMap(mtyp *mapType, ptr unsafe.Pointer) {
	m := *(*unsafe.Pointer)(ptr)
	if m == nil {
		return
	}

	hm := (*hmap)(m)
	old := hm.B
	mapclear(mtyp, hm)

	hm = makemap(mtyp, 0, hm)
	hm.B = old
	*(*unsafe.Pointer)(ptr) = m
}

It works fine and benefits much on big maps. This is the benchmark results I got on operating a 1000-keys map (one op includes make(map[int]interface{}), set 1000 keys and get 1000 keys):

func BenchmarkMap1000_ResetAndSet(b *testing.B) {
	var pool = sync.Pool{
		New: func() interface{} {
			m := make(map[int]interface{}, 0)
			return &m
		},
	}

	for n := 0; n < b.N; n++ {
		x := pool.Get()
		obj, _ := x.(*map[int]interface{})
		m := *obj
		for i := 0; i < 1000; i++ {
			m[i] = i
			if ni, ok := m[i]; !ok || ni != i {
				b.Fatalf("exp:%v, got:%v", i, ni)
			}
		}
		resetMap(mtype(unpackEface(m).typ), unsafe.Pointer(obj))
		pool.Put(obj)
	}
}

func BenchmarkMap1000_MallocAndSet(b *testing.B) {
	var obj map[int]interface{}

	for n := 0; n < b.N; n++ {
		obj = make(map[int]interface{})
		for i := 0; i < 1000; i++ {
			obj[i] = i
			if ni, ok := obj[i]; !ok || ni != i {
				b.Fatalf("exp:%v, got:%v", i, ni)
			}
		}
	}

	obj[1] = 1
}

//-------------RESULTS----------------
goos: darwin
goarch: amd64
pkg: code.byted.org/gopkg/memset
cpu: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
BenchmarkMap1000_ResetAndSet-16     	   23750	     47376 ns/op	    5957 B/op	     744 allocs/op
BenchmarkMap1000_MallocAndSet-16    	    9390	    119347 ns/op	  128288 B/op	     785 allocs/op

[randall77]

What's wrong with

for k := range m {
  delete(m, k)
}

?
That gives you an empty map with the bucket array of the starting m. At least, until #20135 is implemented.

[AsterDY]

What's wrong with

for k := range m {
  delete(m, k)
}

?
That gives you an empty map with the bucket array of the starting m. At least, until #20135 is implemented.

Actually I bench this scenario too, and it loss %2~%8 cpu performance since runtime.memclr() is more effecient than foreach iteration...

[martisch]

since runtime.memclr() is more effecient than foreach iteration...

there is no iteration in the generated code. Newer go compilers optimise the above to a single call to runtime.mapclear which uses memclr.
https://godbolt.org/z/vxKGzb639

Note that this doesnt work for key types that are not reflexive for ==.

A simple memclear allone doesnt suffice and other data in the map needs to be reset too to make it reusable.

go/src/runtime/map.go

Line 978 in db8142f

func mapclear(t *maptype, h *hmap) {

[AsterDY]

since runtime.memclr() is more effecient than foreach iteration...

there is no iteration in the generated code. Newer go compilers optimise the above to a single call to runtime.mapclear which uses memclr.
https://godbolt.org/z/vxKGzb639

Note that this doesnt work for key types that are not reflexive for ==.

A simple memclear allone doesnt suffice and other data in the map needs to be reset too to make it reusable.

go/src/runtime/map.go

Line 978 in db8142f

func mapclear(t *maptype, h *hmap) {

I got it. As you mentioned, if the key type is complex like interface{}, this compiling-time optimization doesn't work. So my way still gets advantage?

[randall77]

So my way still gets advantage?

Sure. So the question is, is it worth complicating the API? And what would that API look like? How easy is it to use and/or how easy is it to avoid misusing it?

We tend to come down on the side of a cleaner API.

[OneOfOne]

@randall77

Since we have delete(m, k), can't we make k optional?
So basically delete(m) would internally call mapclear resetMap(m).

[randall77]

Having delete(m) clear the whole map is possible. I don't think it is worth complicating the language spec for it, though. I think we'd need a stronger motivation than I've seen so far. Sure, every proposal is useful, but changes to the language need to pass a very high bar. Possible evidence could be that this problem is pervasive (e.g. find lots of instances where people would have used this feature, but had to resort to some lower-quality solution instead).

I'm not sure I understand the distinction between mapclear and resetMap. What different does the latter do?
(If it allows you to change the type of the keys or values, then it gets significantly more complicated.)

[AsterDY]

@randall77

Since we have delete(m, k), can't we make k optional?
So basically delete(m) would internally call mapclear resetMap(m).

I agree with your proposal . delete(m) is more definitive and concise for users who even don't know the compiler's trick（including me 👀), therefore them can remind themselves to reuse the map as required

[rsc]

We already recognize and optimize

for i := range x {
   x[i] = 0
}

as memset. Whatever fast implementation of map clearing we might come up with could be triggered just as easily by

for k := range m {
   delete(m, k)
}

right?

The question is really whether the optimization of that is "zero all the storage" or "shrink".