flow.util: Basic_blob - Empty base class optimization & members order optimization.

[ygoldfeld]

Filed by @kinokrt pre-open-source:

The {{template<typename Allocator, bool S_SHARING_ALLOWED> flow::util::Basic_blob}} is a generic low-level container that could greatly benefit from [empty base class optimization|https://en.cppreference.com/w/cpp/language/ebo]. Rationale? It is quite common for the {{Allocator}} to be stateless, as seen in the default {{std::allocator<uint8_t>}}.

What does this mean in the end? The basic blob is generic, but one possible format is like this:

{code:c++}
class Basic_blob
{
boost::shared_ptr<uint8_t[]> buf_ptr;
std::allocator<uint8_t> allocator;
size_t capacity;
size_t start;
size_t size;
}
{code}

Which is 48B.

After [empty base class optimization|https://en.cppreference.com/w/cpp/language/ebo] - Example implementation:
{code:c++}
class Basic_blob
{
boost::shared_ptr<uint8_t[]> buf_ptr;
boost::compressed_pair<size_t, std::allocator<uint8_t>> capacity_and_allocator;
size_t start;
size_t size;
}
{code}

We get 40B. Keep in mind the 'dynamic' nature of the data types that may end up in the Basic_blob. This consideration is important due to possible padding issues when incorrectly ordered. However, this challenge can be addressed through compile-time programming to determine the correct order. Of course multiple solutions are in play...

Another example is this possible layout:
{code:c++}
class Basic_blob
{
boost::movelib::unique_ptr<uint8_t[]> buf_ptr;
std::allocator<uint8_t> allocator;
size_t capacity;
size_t start;
size_t size;
};
{code}

Which is 40B. But after EBO:
{code:c++}
class Basic_blob
{
boost::movelib::unique_ptr<uint8_t[]> buf_ptr;
boost::compressed_pair<size_t, std::allocator<uint8_t>> capacity_and_allocator;
size_t start;
size_t size;
};
{code}

We get 32B.

---

Addendum by @ygoldfeld: Use https://www.boost.org/doc/libs/1_84_0/libs/utility/doc/html/utility/utilities/compressed_pair.html for EBC optimization.