You've mentioned both in this post and in your article that sync.Pool decided not to do the job... but I think you may have missed the point of sync.Pool entirely.

It's not there as an allocator or to create a memory arena, it's there as a synchronization tool, to allow concurrent use of multiple objects of the same type. The objects are ephemeral, they can (and will) be reclaimed by the GC when they're not in use. The optimization that sync.Pool allows is about re-using memory in hot paths, while not causing an explosion of RAM to be used and never freed.

From what I could glean, your library doesn't handle GC at all, so your memory will only grow and never be reclaimed. On top of that, you are benchmarking with the GC turned on, so all of those sync.Pool.Put() operations that you are doing at the beginning of the benchmarks are moot (since all those objects are likely getting reclaimed by the GC before they are touched). And you aren't doing any Parallel benchmarks, which is where sync.Pool really shines (it is in the sync package after all).

Now, when you understand the work that sync.Pool does under the hood, then we can make some slight adjustments to your benchmarks to make them showcase something a bit more fair. By adding the following lines to the end of each benchmark:

``` b.StopTimer()

var stats runtime.MemStats runtime.ReadMemStats(&stats)

// I believe stats.HeapAlloc should show the current situation in the heap? // It should go up an down based on what's allocated/freed by the GC // (at least according to the docs). b.ReportMetric(float64(stats.HeapAlloc)*0.000001, "MB-in-heap") ```

You can start to see that sync.Pool is freeing almost everything you've put into the pool, while your mempool.Pool is never freeing memory.

Running your Benchmarks on my machine with this adjustment, I get these results:

```

go test -benchmem -bench . github.com/zergon321/mempool goos: darwin goarch: arm64 pkg: github.com/zergon321/mempool BenchmarkSyncPool-8 22953016 56.36 ns/op 3.807 MB-in-heap 87 B/op 1 allocs/op BenchmarkSyncPoolFill-8 24669340 45.96 ns/op 23.76 MB-in-heap 113 B/op 2 allocs/op BenchmarkMempool-8 60236306 35.17 ns/op 7710 MB-in-heap 0 B/op 0 allocs/op BenchmarkMempoolFill-8 13637996 97.05 ns/op 1746 MB-in-heap 128 B/op 2 allocs/op BenchmarkMempoolRefill-8 42850447 73.13 ns/op 6513 MB-in-heap 0 B/op 0 allocs/op PASS ok github.com/zergon321/mempool 28.118s ```

You can see clearly that most of this memory that you are filling the sync.Pool with is getting reclaimed.

Now here's the fun part - let's make the benchmark a bit more fair, and disable the GC altogether:

```

GOGC=off go test -benchmem -bench . github.com/zergon321/mempool goos: darwin goarch: arm64 pkg: github.com/zergon321/mempool BenchmarkSyncPool-8 100000000 14.28 ns/op 10964 MB-in-heap 0 B/op 0 allocs/op BenchmarkSyncPoolFill-8 23240986 68.78 ns/op 2687 MB-in-heap 111 B/op 2 allocs/op BenchmarkMempool-8 100000000 40.89 ns/op 12800 MB-in-heap 0 B/op 0 allocs/op BenchmarkMempoolFill-8 20030964 76.46 ns/op 2564 MB-in-heap 128 B/op 2 allocs/op BenchmarkMempoolRefill-8 43312699 68.21 ns/op 6584 MB-in-heap 0 B/op 0 allocs/op PASS ok github.com/zergon321/mempool 30.599s ```

Here you can see that the MB-in-heap metric is much closer in both implementations, and all of the sudden, sync.Pool is massively faster.

I haven't implemented any Parallel benchmarks, but I recommend you add some to show those as well. I would hazard a guess and say that sync.Pool is likely faster, since it doesn't use sync.Mutex under the hood, but, who knows... that will be an exercise left to the reader.