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