When sampling triggers, we skip SOO and allocate a backing array. We must do this because the HashtablezInfoHandle is part of the heap allocation (along with the control bytes and slots). By default, we sample 1 in ~1024 hashtables when sampling is enabled. This will impact performance because (a) we won't benefit from SOO so we would have worse data locality (more cache/TLB misses), and (b) the backing array capacity will be 3 instead of 1 so (b.1) we skip the rehash after the second insertion and (b.2) we potentially waste up to two slots worth of memory. We also add an soo_capacity field to HashtablezInfo to allow for distinguishing which sampled tables may otherwise have been SOO - this will allow us to know approximately what fraction of tables are in SOO mode. PiperOrigin-RevId: 617252334 Change-Id: Ib48b7a4870bd74ea3ba923ed8f350a3b75dbb7d3
| Name |
Last commit
|
Last Update |
|---|---|---|
| .. | ||
| algorithm | Loading commit data... | |
| base | Loading commit data... | |
| cleanup | Loading commit data... | |
| container | Loading commit data... | |
| copts | Loading commit data... | |
| crc | Loading commit data... | |
| debugging | Loading commit data... | |
| flags | Loading commit data... | |
| functional | Loading commit data... | |
| hash | Loading commit data... | |
| log | Loading commit data... | |
| memory | Loading commit data... | |
| meta | Loading commit data... | |
| numeric | Loading commit data... | |
| profiling | Loading commit data... | |
| random | Loading commit data... | |
| status | Loading commit data... | |
| strings | Loading commit data... | |
| synchronization | Loading commit data... | |
| time | Loading commit data... | |
| types | Loading commit data... | |
| utility | Loading commit data... | |
| BUILD.bazel | Loading commit data... | |
| CMakeLists.txt | Loading commit data... | |
| abseil.podspec.gen.py | Loading commit data... |