Suboptimal padding of the optional type

[logankaser]

The memory layout of the optional type is currently like this:

bool
Type

This means that if Type requires more alignment than bool, there will be padding.
For example, if Type=double, the memory might look like so:
bpppppppdddddddd b = bool, p = padding, d = double. That means almost half of the size of the type is just padding.
If instead the memory layout was like:

Type
bool

There would not be this problem, as bool has no padding requirement (well, at least on x86).
I'm assuming there is a good reason for this design, so pardon my ignorance, but I was wondering what the reason
for this is? I discovered this recently when replacing optional with some separate bool members, halved the
size of an important type in my codebase.

[derekmauro]

Initially I thought you were right about the padding being suboptimal. The rule of thumb for optimizing struct size is normally to sort the members by decreasing size, but see also the famous The Lost Art of Structure Packing.

The more I thought about it though, I don't think the order makes difference when it comes to the size of the optional. Even though bool has no padding requirement, the entire struct may require padding after the bool to be correctly aligned.

When you say you replaced optional with separate bool members, I think that you actually meant that you grouped the bools together? The Boost doc on optional performance considerations actually points this out.

Therefore I would say that the optional type really isn't a zero-cost abstraction. It is more about code readability.

I can't tell if there is any good reason to re-order the layout of optional. It is possible that if the bool always needs to be checked before accessing the value, having it come before the value may pull some part of the value into the cache as well.

[logankaser]

The caching consideration is a great insight, that's probably the best justification for this.
Any type smaller than 57 bytes would be guaranteed to be in the same cache line, which
is likely a performance win in real code over smaller padding sizes in many situations, and
it makes sense what you said about it not being zero-cost and more for readability.

A smaller example I found recently was:

struct {
  Eigen::Vector2d a;
  absl::optional<Eigen::Vector2d> b;
  bool flag;
};

Which is 64 bytes,
but can instead be:

struct {
  Eigen::Vector2d a;
  Eigen::Vector2d b;
  bool has_b;
  bool flag;
};

Which is 40 bytes.
That fits with the advice of the boost documentation regarding grouping bools. I guess it was just
my turn to discover this performance tidbit.

Thanks for taking the time to think about this, I'm satisfied by that explanation!