You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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}
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.
The text was updated successfully, but these errors were encountered: