为什么Sysutils.RenameFile内联？

Question

  

[dcc32提示] H2443内联函数'RenameFile'尚未展开   因为未在USES列表中指定单位'Winapi.Windows'

据我所知，内联函数可以使代码更快。但我只看到了紧张的地方。例如，在一个大循环中调用一个小函数。

但如何内联IO功能可以提高速度？我的意思是通过内联RenameFile你可以获得几微秒。但是如果磁盘忙，执行函数本身可能需要几毫秒，甚至几十毫秒。

更重要的是，如果您使用的是RenameFile，那么您可能正处于执行其他I / O操作的代码块中。因此，这段代码将花费大量时间。所以，现在的收益更加微不足道。

Answer 1

RenameFile是内联的，因为它是对另一个函数的简单调用。

这就是它的样子：

function RenameFile(const OldName, NewName: string): Boolean;
{$IFDEF MSWINDOWS}
begin
  Result := MoveFile(PChar(OldName), PChar(NewName));
end;

通过内联此功能，SysUtils.RenameFile的调用将被WinApi.Windows.MoveFile的调用取代。

这具有以下优点：

• 您保存一个电话，而不是两个电话，您只有一个电话。
• 您的通话代码大小完全相同。
• CPU保留分支预测的返回地址列表（返回堆栈缓冲区）;通过消除冗余调用，它可以节省此缓冲区中的空间，如果调用堆栈太深，可以防止错误预测。
• 生成的代码较小，因为RenameFile本身已被删除。

所以内联非常值得麻烦，特别是在调用堆栈可能变深的递归代码中，CPU将开始错误预测返回，因为返回堆栈缓冲区溢出（某些CPU只有8个条目，顶部CPU的行有24个条目）。

作为一项规则，每个简单调用另一个例程的例程都应该始终内联。

正确预测的回报会花费一个周期，错误预测会耗尽管道并花费25个周期或更多周期;因为需要从内存而不是缓冲区中获取返回地址，所以会添加更多延迟。

你是正确的，这些优势在磁盘IO代码中都不重要，但这并没有减损像这样的简单重定向函数应该总是内联的事实。