1. std::function 的成本

std::function 是一个通用的、类型擦除的函数包装器，它非常方便，可以存储和调用任何可调用对象（函数、lambda、函数对象、bind表达式等）。然而，这种灵活性是有代价的。

主要成本来源：

a) 类型擦除（Type Erasure）的开销
这是 std::function 最根本的成本。为了实现“可以容纳任何可调用对象”的目标，它必须在编译时隐藏所存储对象的实际类型。这是通过虚函数或类似的技术实现的。通常，std::function 内部会有一个指向基类的指针，该基类定义了 invoke, copy, destroy 等虚函数。具体的可调用对象则存储在一个派生类中。

• 内存开销：std::function 本身有一个大小。标准允许实现使用小对象优化（Small Object Optimization, SOO），类似于 std::string。
  • 如果存储的可调用对象很小（例如，一个无捕获的lambda，只是一个函数指针），它可以直接存储在 std::function 的内部缓冲区中，避免一次堆分配。
  • 如果对象较大（例如，一个捕获了很多变量的lambda），则需要在堆上分配内存来存储它。
  • 典型的 std::function 大小是 32 或 64 字节（取决于平台和实现），这比一个普通函数指针（通常为 8 字节）大得多。

b) 动态分配（可能发生）
如上所述，对于大的可调用对象，会有一次堆分配和释放的成本。这在性能关键的代码路径（例如紧循环、高频交易）中可能是不可接受的。

c) 间接调用（Indirect Call）的开销
调用 std::function 本质上是一个通过函数指针的间接调用。首先需要从 std::function 对象中加载出正确的函数地址，然后进行调用。这阻止了内联等优化，并且比直接调用一个函数指针或成员函数有更高的预测失败 penalty。

d) 拷贝成本
拷贝一个 std::function 可能涉及拷贝其底层的可调用对象，这可能很昂贵（例如，如果它捕获了一个大的容器）。移动操作通常更高效，但标准并不保证它一定是 noexcept。

性能建议：

1. 在性能不敏感的代码中使用：对于UI回调、事件处理器、初始化代码等，std::function 的便利性远大于其微小的开销。
2. 在热路径（Hot Path）中避免使用：在循环的核心部分或需要极致性能的地方，考虑替代方案。
3. 使用模板替代：

   // 避免这个：
   // void registerCallback(std::function<void()> func);// 使用这个（如果可能在头文件中实现）：
   template<typename Callable>
   void registerCallback(Callable&& func) {// ... 存储 func ...
   }
   

   模板保留了可调用对象的原始类型，允许内联，完全避免了 std::function 的类型擦除开销。缺点是可能导致代码膨胀，并且回调的存储变得复杂。
4. 使用函数指针（如果适用）：如果你只需要处理自由函数或静态成员函数，直接使用函数指针 void (*callback)() 是零开销的。
5. 使用特定类型的函数对象：如果你自己设计回调系统，可以定义一个接口基类，让用户从它派生。这给了你虚调用的成本，但避免了动态分配（如果你自己管理对象生命周期的话）。

总结：std::function 的成本是“一次可能的堆分配 + 每次调用的间接调用成本”。在大多数情况下没问题，但在需要极致性能时需警惕。

---

2. 异常处理的真实开销

C++异常处理的性能开销是一个复杂的话题，可以分为“成功路径”（没有异常抛出）和“失败路径”（抛出并捕获异常）来讨论。

a) 成功路径（No-except Path）的开销

传统的观点是“零开销”或“近乎零开销”。这个说法的意思是，如果你不抛出异常，你几乎不需要为异常处理机制付出性能代价。

• 现代实现（如Itanium C++ ABI，被Linux/macOS上的GCC/Clang使用）：主要使用“表驱动”的方法。编译器会生成额外的静态数据（LSDA - Language Specific Data Area 和 unwind tables），这些数据指示如何展开堆栈和查找catch块。这些数据不占用指令缓存（I-cache），但占用数据缓存（D-cache）和磁盘空间。函数本身的代码路径没有额外的指令来检查错误。错误处理逻辑完全存在于这些静态表中。
• Windows x64：使用类似的方法，但具体细节不同。

所以，成功路径的运行时性能开销确实非常低。主要的成本是二进制文件体积的轻微增大和潜在的缓存占用。

b) 失败路径（Exceptional Path）的开销

抛出和捕获异常的开销是巨大的。这是一个非常重量级的操作。其过程大致如下：

1. 抛出：throw ex;

   • 运行时库需要创建异常对象（可能在堆上）。
   • 它开始栈回溯（Stack Unwind）：从当前函数开始，沿着调用链向上走。
   • 对于每一个栈帧，它查询静态的unwind表，执行该范围内对象的析构函数（RAII！），并检查当前函数是否有匹配的 catch 块。
   • 这个过程涉及很多查找和操作，速度很慢。抛出异常比正常的函数返回慢数个数量级。

2. 捕获：catch(...)

   • 找到匹配的catch块后，控制流会跳转到那里，并初始化异常参数。

关键点：异常处理的设计初衷是让“失败情况”（异常）变得昂贵，而让“成功情况”（无异常）变得廉价。它优化了非异常路径。

重要的现代考量：noexcept

noexcept 关键字在现代C++中至关重要，它不仅仅是异常规范。

1. 编译器优化机会：编译器知道 noexcept 函数不会抛出异常，这可以允许更积极的优化。例如，std::vector 在重新分配时，如果移动构造函数是 noexcept 的，它会使用更高效的移动操作；否则，它必须使用更保守的拷贝操作。
2. 程序终止 vs 可恢复错误：noexcept 表明这是一个“不该失败”的函数。如果它真的抛出了异常，std::terminate 会被立即调用，而不是进行昂贵的栈展开。这在某些情况下反而是更可取的（例如，发生了一个不可恢复的逻辑错误）。
3. 接口设计：向用户传达该函数不会失败的信。

性能建议与最佳实践：

1. 不要使用异常用于正常的控制流：绝对不要用 throw/catch 来代替像 break 这样的简单操作。异常只应用于真正的、罕见的“异常”情况（文件未找到、网络断开、无效输入等）。
2. 在性能关键的代码中，考虑错误码替代异常：对于可预测的、频繁发生的错误（例如，解析用户输入时常见的格式错误），使用错误码（如 std::expected (C++23), std::optional, 或自定义枚举）可能性能更高，因为检查一个返回值的成本极低。
3. 广泛使用 noexcept：对于明确不会抛出异常的函数（例如，getters、简单计算、析构函数），将其标记为 noexcept。这既是给编译器的优化提示，也是给其他程序员的API文档。
4. 了解你的编译器和目标平台：虽然主流实现的开销模型相似，但在极端嵌入式平台上可能不同，有时甚至会完全禁用异常（-fno-exceptions）。

总结：异常处理的真实开销是“成功路径成本极低，失败路径成本极高”。它非常适合处理罕见的、真正的错误，但不适合处理频繁的、预期的错误情况。正确使用 noexcept 是现代C++高性能编程的关键部分。

---

总体结论

• std::function：为你带来的便利性付费（类型擦除、可能的动态分配、间接调用）。在热路径中慎用。
• 异常：为你处理“异常情况”的能力付费（庞大的失败路径开销、增加的二进制大小）。不要将其用于控制流，并积极使用 noexcept。