我知道内联是对编译器的提示或请求,用于避免函数调用开销。

那么,在什么基础上可以确定一个函数是否是内联的候选人? 在哪种情况下应该避免内联?


当前回答

在决定是否使用内联时,我通常记住以下想法:在现代机器上,内存延迟可能是比原始计算更大的瓶颈。众所周知,经常调用的内联函数会增加可执行文件的大小。此外,这样的函数可以存储在CPU的代码缓存中,当需要访问代码时,这将减少缓存失败的数量。

因此,您必须自己决定:内联是否会增加或减少生成的机器代码的大小?调用该函数会导致缓存丢失的可能性有多大?如果它遍布整个代码,那么我认为可能性很高。如果它被限制在一个单一的紧密循环,那么可能性很低。

我通常使用内联的情况下,我列出如下。然而,当您真正关心性能时,概要分析是必不可少的。此外,您可能希望检查编译器是否真的接受了提示。

在紧密循环中调用的简短例程。 非常基本的访问器(get / set)和包装器函数。 不幸的是,头文件中的模板代码会自动获得内联提示。 像宏一样使用的短代码。(例如min() / max()) 简短的数学程序。

其他回答

过早的优化是万恶之源!

根据经验,我通常只内联“getter”和“setter”。一旦代码可以工作并且稳定,分析就可以显示哪些函数可以从内联中受益。

另一方面,大多数现代编译器都有很好的优化算法,并且会内联您应该内联的内容。

推理——编写内联单行函数,以后再考虑其他函数。

只有当函数代码很小时,才应该使用内联函数限定符。如果函数比较大,则应该使用普通函数,因为节省内存空间可以换取相对较小的执行速度牺牲。

我经常使用内联函数不是为了优化,而是为了使代码更具可读性。有时代码本身比注释、描述性名称等更短、更容易理解。例如:

void IncreaseCount() { freeInstancesCnt++; }

读者可以立即了解代码的完整语义。

在决定是否使用内联时,我通常记住以下想法:在现代机器上,内存延迟可能是比原始计算更大的瓶颈。众所周知,经常调用的内联函数会增加可执行文件的大小。此外,这样的函数可以存储在CPU的代码缓存中,当需要访问代码时,这将减少缓存失败的数量。

因此,您必须自己决定:内联是否会增加或减少生成的机器代码的大小?调用该函数会导致缓存丢失的可能性有多大?如果它遍布整个代码,那么我认为可能性很高。如果它被限制在一个单一的紧密循环,那么可能性很低。

我通常使用内联的情况下,我列出如下。然而,当您真正关心性能时,概要分析是必不可少的。此外,您可能希望检查编译器是否真的接受了提示。

在紧密循环中调用的简短例程。 非常基本的访问器(get / set)和包装器函数。 不幸的是,头文件中的模板代码会自动获得内联提示。 像宏一样使用的短代码。(例如min() / max()) 简短的数学程序。

最好的方法是分析你的程序,把那些被多次调用并消耗CPU周期的小函数标记为内联函数。这里的关键字是“小”——一旦函数调用开销与函数中花费的时间相比可以忽略不计,那么内联它们就没有意义了。

我建议的另一种用法是,如果你有一些小函数在性能关键代码中经常被调用,以至于缓存不相关,你可能也应该内联这些函数。同样,这也是侧写师应该能够告诉你的。