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.