use a single malloc/free call for F14VectorMap and Set
Summary:
Before this diff the vector storage policy for F14 allocated the
chunk array and the value_type array via separate calls to the allocator.
After this diff they are performed via a single allocation using a byte
allocator rebound from the original value allocator. This will halve
the number of calls to malloc and free from a majority of F14FastMap-s
and F14FastSet-s (and from all F14VectorMap and F14VectorSet).
The optimization is likely to be most important for small sets and maps.
In a microbenchmark that just creates and destroys 1-element
F14VectorMap-s, this diff was a 20% CPU win.
This diff is not pure win. The unified allocation of
`(64+10*sizeof(value_type))*N` causes more internal fragmentation in
jemalloc for most value_type sizes than separate allocations of `64*N`
and `10*sizeof(value_type)*N`. 48-byte value_type is probably the most
affected in practice; this diff will increase the memory footprint
of vector-policy tables with 48-byte keys by 13% once internal memory
fragmentation is taken into account.
Taking into account the default jemalloc allocation classes,
sizeof(value_type) | footprint change
--------------------|--------------------
24 | 1.03797
32 | 1.
40 | 1.07462
48 | 1.1273
56 | 1.0185
64 | 1.06558
72 | 1.02742
80 | 1.02672
88 | 1.
96 | 1.
104 | 1.05961
112 | 1.05849
120 | 0.965071
128 | 1.10305
136 | 0.942188
144 | 0.942984
152 | 1.05624
160 | 1.05549
168 | 0.927757
176 | 1.0238
184 | 1.02353
192 | 1.02327
200 | 1.08255
208 | 1.08173
216 | 1.08093
224 | 1.08015
232 | 0.981946
240 | 0.982102
248 | 0.982255
256 | 1.12316
Reviewed By: yfeldblum
Differential Revision: D8485933
fbshipit-source-id: 1a7df390e11e71e1f56f23527aebec4806eb03d1
Showing
Please register or sign in to comment