Discussion: allowing pooling of bitmaps

The current implementation does a lot of allocations so it'd be beneficial to allow pooling of bitmaps. This'd amortise the cost of allocations for long running applications.

Something like:

b := roaring.New()
// do whatever to b
// eventually once you're done with it 
b.Reset() // or maybe changing internals of b.Clear() 

The motivation for this was this benchmark:

// BenchmarkCachedObject does ~20% more allocs than BenchmarkClone.
func BenchmarkClone(b *testing.B) {
	initPL := roaring.New()
	for i := 0; i < b.N; i++ {
		initPL.Add(uint32(i))
	}

	b.ResetTimer()
	b.ReportAllocs()

	for i := 0; i < b.N; i++ {
		copy := initPL.Clone()
		if copy.GetCardinality() != initPL.GetCardinality() {
			b.Error("unequal duplicate size")
		}
	}
}

func BenchmarkCachedObject(b *testing.B) {
	initPL := roaring.New()
	for i := 0; i < b.N; i++ {
		initPL.Add(uint32(i))
	}

	copy := roaring.New()
	b.ResetTimer()
	b.ReportAllocs()

	for i := 0; i < b.N; i++ {
		copy.Clear()
		copy.Or(initPL)
		if copy.GetCardinality() != initPL.GetCardinality() {
			b.Error("unequal duplicate size")
		}
	}
}

Start by reading the roaring.New, Clear, Clone, and Or entry points referenced in the issue, along with the BenchmarkClone and BenchmarkCachedObject examples. Compare their allocation behavior and determine the intended pooling lifecycle. Done means a decided pooling API preserves bitmap correctness while reducing allocations in the benchmark.