Re: slab allocator performance issues

Hi,

I spent a bit of time benchmarking this - the first patch adds an
extension with three functions, each executing a slightly different
allocation pattern:

1) FIFO (allocates and frees in the same order)
2) LIFO (frees in reverse order)
3) random

Each function can also do a custom number of iterations, each allocating
and freeing certain number of chunks. The bench.sql script executes
three combinations (for each pattern)

1) no loops
2) increase: 100 loops, each freeing 10k chunks and allocating 15k
3) decrease: 100 loops, each freeing 10k chunks and allocating 5k

The idea is to test simple one-time allocation, and workloads that mix
allocations and frees (to see how the changes affect reuse etc.).

The script tests this with a range of block sizes (1k-32k) and chunk
sizes (32B-512B).

In the attached .ods file with results, the "comparison" sheets are the
interesting ones - the last couple columns compare the main metrics for
the two patches (labeled patch-1 and patch-2) to master.

Overall, the results look quite good - patch-1 is mostly on par with
master, with maybe 5% variability in both directions. That's expected,
considering the patch does not aim to improve performance.

The second patch brings some nice improvements - 30%-50% in most cases
(for both allocation and free) seems pretty nice. But for the "increase"
FIFO pattern (incrementally allocating/freeing more memory) there's a
significant regression - particularly for the allocation time. In some
cases (larger chunks, block size does not matter too much) it jumps from
25ms to almost 200ms.

This seems unfortunate - the allocation pattern (FIFO, allocating more
memory over time) seems pretty common, and the slowdown is significant.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company