建议编译器有选择地内联函数调用

假设我有以下代码：

struct Foo {
  void helper() { ... }
  void fast_path() { ...; helper(); ... }
  void slow_path1() { ...; helper(); ... }
  void slow_path2() { ...; helper(); ... }
};

该方法对fast_path()性能至关重要，因此应尽一切努力（使之尽可能快）。方法slow_path1()和slow_path2()性能不是关键。

根据我的理解，典型的编译器可能会查看此代码，并决定是否内联该代码helper()是否足够复杂，以减小总指令大小，因为这helper()是多个方法函数之间共享的。helper()如果不存在慢路径方法，则同一编译器可以内联。

鉴于我们期望的性能特征，我们希望编译器内联到helper()inside的调用fast_path()，但希望编译器在slow_path1()和中使用默认行为slow_path2()。

一种解决方法是让慢路径函数定义和调用fast_path()驻留在单独的编译单元中，以使编译器永远不会看到与helper()共享的用法fast_path()。但是保持这种分离需要特别注意，并且不能通过编译器强制实施。另外，文件（Foo.h，FooINLINES.cpp，现在还有Foo.cpp）的泛滥是不受欢迎的，而且附加的编译单元使原本可能仅是标头的库的构建变得复杂。

有没有更好的办法？

理想情况下，我想要一个do_not_inline_function_calls_inside_me可以这样使用的新c ++关键字：

  do_not_inline_function_calls_inside_me void slow_path1() { ... }
  do_not_inline_function_calls_inside_me void slow_path2() { ... }

另外，也可以这样输入一个inline_function_calls_inside_me关键字：

  inline_function_calls_inside_me void fast_path() { ... }

请注意，这些假设的关键字修饰了*_path*()方法，而不是helper()方法。

您可能会遇到这类性能需求的示例上下文是编程竞赛，其中每个参与者编写一个应用程序，侦听A和B型稀疏的全局数据广播。收到B型广播时，每个应用程序都必须执行计算取决于先前广播的A型消息的顺序，并将计算结果提交给中央服务器。每个B型广播的第一个正确响应者都得分。计算问题的性质可能允许对A型更新执行预计算；快速进行操作没有任何优势。