Performance considerations with std::optional

While std::optional is a very useful tool, there are a few performance considerations to keep in mind:

1. Size overhead: An std::optional object is typically the size of the contained object plus an additional boolean to track whether the optional contains a value. This means that std::optional may not be suitable for very large objects or in situations where memory is very constrained.
2. Value construction and destruction: When an std::optional is assigned a value, the value is constructed inside the optional. When the optional is destroyed or reassigned, the value is destroyed. This construction and destruction can have performance implications, especially if the contained type is expensive to construct or destroy.
3. Accessing values: Accessing the value in an std::optional (using * or ->) requires a branch to check if the optional contains a value. This branch can have a slight performance impact, especially in tight loops.
4. Monadic operations: The monadic operations (and_then(), or_else(), transform()) are convenient, but they involve function calls and potentially the creation and destruction of temporary std::optional objects, which can have performance implications.

Here's an example illustrating the first two points:

1#include <optional>
2
3class ExpensiveClass {
4 public:
5  ExpensiveClass() {
6    // expensive initialization
7  }
8  ~ExpensiveClass() {
9    // expensive cleanup
10  }
11};
12
13int main() {
14  std::optional<ExpensiveClass> opt;
15
16  // This will construct an ExpensiveClass object
17  opt = ExpensiveClass();
18
19  // This will destroy the ExpensiveClass object
20  opt = std::nullopt;
21}

In most cases, the performance implications of std::optional are minor and outweighed by the benefits in terms of code clarity and safety. However, in performance-critical code or when working with very large objects, it's good to be aware of these considerations.