内联方法的好处是什么

Question

我最近看到我的朋友编写的一个 Util 类有很多内联方法。该类与图像有关，并且具有诸如

public static inline function resize ( img:Image, width:Int, height:Int)
{
    //... method implementation goes here.
}

我问他为什么要使用内联。我知道编译器会更改

var img:Image = ImgUtil.resize(img, 100, 100);

到

var img:Image = // Implementation of method here

他只是说，它减少了对函数的调用，并且只在实用程序方法上使用它们。每次复制相同的代码不会增加程序大小吗？

现在需要这个吗？如果需要，应该在什么时候使用它们？

编辑

我在Patrick提供的一个列表中列出了大多数问题和优点，以帮助那些不想浏览链接的未来观众。

问题

用扩展的函数体替换调用站点可能会以几种方式恶化性能：

< li >在代码大小比速度更重要的应用程序中，如许多嵌入式系统，内联通常是不利的，除非是非常小的函数，如简单的赋值函数方法。 < li >代码大小的增加可能会导致一小部分关键代码不再适合缓存，从而导致缓存缺失和速度下降。 < li >内联过程中添加的变量可能会消耗额外的寄存器，在寄存器压力已经很高的区域，这可能会强制溢出，从而导致额外的RAM访问。 < li >语言规范可能允许程序对过程的参数进行额外的假设，而这些假设在过程被内联后就不能再进行了。 < li >如果代码大小增加太多，可能会超出资源限制(如RAM大小),导致程序无法运行或导致系统颠簸。今天，除了非常激进的内联之外，这不太可能成为桌面或服务器计算机的问题，但是对于嵌入式系统来说，这仍然是一个问题。

通常，编译器开发人员会记住这些问题，并在编译器中加入启发式，以选择内联哪些函数，从而在大多数情况下提高性能，而不是恶化性能。

优势:

内联扩展本身是一种优化，因为它消除了调用的开销，但它作为启用转换更为重要。也就是说，一旦编译器在其调用站点的上下文中扩展函数体（通常使用可能是固定常量的参数），它就可以执行以前不可能的各种转换。例如，条件分支可能总是为真或总是假在这个特定的调用站点上。这反过来又可以实现死代码消除、循环不变代码运动或归纳变量消除。

Answer 1

维基百科会告诉你比你需要的更多的信息。