delphi - 为什么 Sysutils.RenameFile 是内联的？

Question

[dcc32 Hint] H2443 Inline function 'RenameFile' has not been expanded because unit 'Winapi.Windows' is not specified in USES list

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

但是内联 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 代码中都不会起作用，但这并没有减损像这样的简单重定向函数应该始终内联的事实。