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