[SERVER-85393] use monotonic_buffer_resource to reduce allocations in MetricTree merging algorithm Created: 18/Jan/24  Updated: 22/Jan/24

Status: In Progress
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Billy Donahue Assignee: Blake Oler
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Participants:

 Description   

As part of PM-1812 and tcmalloc evaluation, we've identified allocator "hot spots" in particular those where allocations are short-lived and freed at the end of a block scope in an RAII-compatible way. C++17 provides the std::monotonic_buffer_resource which seems perfect for those cases.

we can switch to std::pmr::vector and std::pmr::string inside the functions. We can probably make up a pmr-based BSONObjBuilder as well.
The standard containers do this cool trick of propagating their allocators to their elements. This is a reason to use emplace_back instead of push_back, because emplace_back can sneakily provide the extra allocator argument to the element being constructed. So you can have a vector of vector of vector of strings and all objects would share the allocator that was given to the toplevel object.
https://quuxplusone.github.io/blog/2023/06/02/not-so-quick-pmr/#allocator-extended-constructors
https://www.cppstd17.com/code/pmr/pmr2.cpp.html

The real power here is from not bothering with global new and delete for all the interior elements.

so the monotonic buffer resource ends up owning a very small sequence of geometrically increasing memory buffers. So you have to visit new and delete only a few times, regardless of how many internal allocations the memory resource made.


Generated at Thu Feb 08 06:57:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.