使用内联函数有什么问题？

Question

虽然在某些情况下使用内联函数会非常方便，

内联函数有什么缺点吗？

结论：

显然，使用内联函数并没有错。

但值得注意的是以下几点！

• 过度使用内联实际上会使程序变慢。根据函数的大小，内联它可能会导致代码大小增加或减少。内联非常小的访问器函数通常会减少代码大小，而内联非常大的函数会显着增加代码大小。在现代处理器上，由于更好地使用指令缓存，较小的代码通常运行得更快。 - 谷歌指南

• 随着函数大小的增长，内联函数的速度优势趋于减弱。在某些时候，函数调用的开销与函数体的执行相比变得很小，并且失去了好处 - 来源

• 在少数情况下内联函数可能不起作用：

  • 对于返回值的函数；如果存在 return 语句。
  • 对于不返回任何值的函数；如果存在循环、switch 或 goto 语句。
  • 如果函数是递归的。 -资源

• __inline 关键字仅在您指定优化选项时才内联函数。如果指定了优化，是否 __inline 取决于内联优化器选项的设置。默认情况下，只要运行优化器，内联选项就会生效。如果您指定 optimize ，如果您希望忽略 __inline 关键字，则还必须指定 noinline 选项。 -资源

原文由 prakash 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

值得指出的是，inline 关键字实际上只是给编译器的一个提示。编译器可能会忽略内联，而只是在某个地方为函数生成代码。

内联函数的主要缺点是它会 增加可执行文件的大小（取决于实例化的数量）。这在某些平台（例如嵌入式系统）上可能是一个问题，特别是如果函数本身是递归的。

我还建议使内联函数 非常小- 内联函数的速度优势往往会随着函数大小的增长而减少。在某些时候，函数调用的开销与函数体的执行相比变得很小，并且失去了好处。

原文由 Alan 发布，翻译遵循 CC BY-SA 2.5 许可协议

Answer 2

它可能会增加可执行文件的大小，而且我认为即使您使用了 inline 关键字，编译器也不会总是将它们内联。 （或者相反，就像 Vaibhav 所说的那样？…）

我认为如果函数只有 1 或 2 条语句通常是可以的。

编辑： 这是 linux CodingStyle 文档所说的：

第15章：内联疾病

似乎有一个普遍的误解，即 gcc 有一个神奇的“让我更快”加速选项，称为“内联”。虽然使用内联可能是合适的（例如，作为一种替换宏的方法，参见第 12 章），但通常情况并非如此。大量使用 inline 关键字会导致更大的内核，这反过来又会降低整个系统的速度，这是因为 CPU 占用的 icache 占用空间更大，并且仅仅是因为页面缓存可用的内存更少。考虑一下; pagecache 未命中会导致磁盘查找，这很容易花费 5 毫秒。有很多 cpu 周期可以进入这 5 毫秒。

一个合理的经验法则是不要将 inline 放在其中包含超过 3 行代码的函数中。此规则的一个例外是参数已知为编译时常量的情况，并且由于这种常量，您 知道 编译器将能够在编译时优化您的大部分函数。有关后一种情况的一个很好的示例，请参见 kmalloc() 内联函数。

人们经常争辩说，将内联添加到静态且只使用一次的函数中总是一种胜利，因为没有空间权衡。虽然这在技术上是正确的，但 gcc 能够在没有帮助的情况下自动内联这些，并且当第二个用户出现时删除内联的维护问题超过了告诉 gcc 做它本来会做的事情的提示的潜在价值。

原文由 Paige Ruten 发布，翻译遵循 CC BY-SA 3.0 许可协议