我了解了C语言中的函数指针。 而且每个人都说这会使我的程序运行变慢。 这是真的吗？
我编写了一个程序来验证它。 在两种情况下我得到了相同的结果。(测量时间。)
那么，使用函数指针是不好的吗？ 提前感谢。
回应一些人的问题。 我之所以说“运行变慢”，是因为我在循环中进行了比较。就像这样:
int end = 1000;
int i = 0;
while (i < end) {
fp = func;
fp ();
}
while (i < end) {
func ();
}
因此，我认为函数指针在时间上没有任何区别，并且并不会像许多人所说的那样使程序运行缓慢。
对于实际性能敏感的情况，比如在循环中多次调用函数，性能可能完全相同。这可能听起来很奇怪，因为人们习惯将 C 代码视为由一个抽象的 C 机器执行的，这个“机器语言”与 C 语言本身非常相似。在这种情况下，“默认情况下”，与直接调用相比，间接调用函数的确要慢一些，因为它需要形式上进行额外的内存访问以确定调用目标。
然而，在现实生活中，代码是由真正的计算机执行并由优化编译器编译的，优化编译器具有对底层机器架构的相当好的了解，从而帮助它为那个具体的机器生成最优代码。在许多平台上，执行循环中的函数调用的最有效方法实际上可能导致直接和间接调用的相同代码，从而导致两者具有相同的性能。
例如，考虑 x86 平台。如果我们将直接调用和间接调用“字面上”转换为机器代码，我们可能会得到像这样的结果：
// Direct call
do-it-many-times
call 0x12345678
// Indirect call
do-it-many-times
call dword ptr [0x67890ABC]
前者在机器指令中使用立即操作数，通常比后者更快，因为后者需要从某个独立的内存位置读取数据。
此时让我们记住，x86架构实际上还有一种方法可以向call指令提供操作数。它是在寄存器中提供目标地址。这种格式非常重要的一点是，它通常比以上两种方式都要快。这对我们意味着什么？这意味着一个优化良好的编译器必须并且将会利用这一事实。为了实现上述循环，编译器将尝试在两种情况下都使用通过寄存器调用的方式。如果成功，最终代码可能如下所示：
// Direct call
mov eax, 0x12345678
do-it-many-times
call eax
// Indirect call
mov eax, dword ptr [0x67890ABC]
do-it-many-times
call eax
call 中的立即操作数进行调用）比一个间接调用更慢，只要间接调用的操作数以寄存器的形式提供（而不是存储在内存中）。call转换为寄存器间接的call（使用像ebx而不是eax这样的调用保留寄存器）。在正确预测的情况下，call rel32与其一样快，具有更低的错误预测惩罚，并且可能消耗更少的分支预测资源。Agner Fog的优化指南和Intel的优化手册（x86标签wiki中的链接）都没有提到这种技术，事实上编译器尽可能地反虚拟化（与此相反），即使它们选择不进行内联。 - Peter Cordescall指令。如果内存超出缓存怎么办？显然，200个周期的滞后和流水线惩罚会使任何在这个答案中提到的东西相形见绌，不是吗？ - SO_fix_the_vote_sorting_bug我认为当人们说这句话时，他们指的是使用函数指针可能会阻止编译器优化（内联）和处理器优化（分支预测）。然而，如果函数指针是实现你想要做的事情的有效方法，那么任何其他方法都会有相同的缺点。
除非你的函数指针在性能关键应用程序中的紧密循环中使用或在非常慢的嵌入式系统上使用，否则差异很小。
大多数情况下这种说法是不正确的。首先，如果不使用函数指针的替代方案是什么
if (condition1) {
func1();
} else if (condition2)
func2();
} else if (condition3)
func3();
} else {
func4();
}
这很可能比仅使用单个函数指针要慢得多。虽然通过指针调用函数确实会带来一些（通常可以忽略的）开销，但通常并不是直接调用与通过指针调用之间的差异相关。
第二点，决不要在没有任何测量的情况下为性能进行优化。知道瓶颈在哪里非常困难（读起来几乎不可能），有时这可能会相当反直觉（例如Linux内核开发人员已经开始从函数中删除inline关键字，因为它实际上会影响性能）。
很多人都已经提供了一些好的答案，但我仍然认为有一个点被忽略了。函数指针增加了额外的解引用操作，使它们变慢几个周期，这个数字可以根据不良分支预测而增加（顺便说一句，这几乎与函数指针本身无关）。此外，通过指针调用的函数不能被内联。但是人们所遗漏的是，大多数人使用函数指针作为优化手段。
在c/c++ API中最常见的使用函数指针的地方是作为回调函数。许多API之所以这样做，是因为编写一个在事件发生时调用函数指针的系统比其他方法（如消息传递）更有效率。就我个人而言，我曾将函数指针用作更复杂的输入处理系统的一部分，其中键盘上的每个按键都通过跳转表映射到一个函数指针。这使我能够从输入系统中删除任何分支或逻辑，并且只需处理按键按下事件即可。
之前的回复中有很多重要的观点。
然而，需要看一下 C qsort 比较函数。因为比较函数无法内联，需要遵循标准的基于栈的调用约定，所以对于整数键而言，排序的总运行时间可能会慢上数量级（更确切地说是 3-10 倍），与直接可内联调用的相同代码相比。
典型的内联比较将是一系列简单的 CMP 指令和可能的 CMOV/SET 指令序列。函数调用还会产生 CALL 的开销，设置栈帧，进行比较，拆卸栈帧并返回结果。请注意，由于 CPU 管道长度和虚拟寄存器，堆栈操作可能会导致管道停顿。例如，如果在执行最后一个修改 eax 的指令之前需要 eax 的值（这通常需要大约 12 个时钟周期在最新的处理器上），除非 CPU 可以按顺序执行其他指令等待它，否则管线停顿将发生。
eax的独立写入将启动一个新的依赖链。请参见http://agner.org/optimize/和[为什么Haswell上的mulss只需要3个周期，与Agner的指令表不同？](//stackoverflow.com/q/45113527)。 - Peter Cordes使用函数指针比直接调用函数慢，因为它是另一层间接引用（需要解除引用指针以获取函数的内存地址）。虽然它比程序可能执行的其他操作（读取文件、向控制台写入）要慢，但这个差异可以忽略不计。
如果需要使用函数指针，请使用它们，因为任何试图避免使用它们并实现相同功能的方法都会比使用函数指针更慢、难以维护。
void foo(int* x) {
*x = 0;
}
void (*foo_ptr)(int*) = foo;
int call_foo(int *p, int size) {
int r = 0;
for (int i = 0; i != size; ++i)
r += p[i];
foo(&r);
return r;
}
int call_foo_ptr(int *p, int size) {
int r = 0;
for (int i = 0; i != size; ++i)
r += p[i];
foo_ptr(&r);
return r;
}
call_foo()的代码生成结果：
call_foo(int*, int):
xor eax, eax
ret
foo() 不仅已经被内联，而且这样做允许编译器消除整个前置循环！生成的代码只需通过将寄存器与自身进行异或运算来清零返回寄存器，然后返回。另一方面，在 call_foo_ptr() 中编译器将不得不为循环生成代码（使用gcc 7.3超过100行），其中大部分代码实际上什么也不做（只要 foo_ptr 仍然指向 foo()）。 （在更典型的情况下，可以预期将小函数内联到热内部循环中可能会将执行时间缩短约一个数量级。）foo_ptr 是 const，那么 call_foo() 和 call_foo_ptr() 将生成相同的代码。但是，这将要求我们放弃由 foo_ptr 提供的间接机会。 foo_ptr 是否应该是 const？如果我们对 foo_ptr 提供的间接引用感兴趣，那么不是，但如果是这种情况，直接函数调用也不是一个有效的选择。