c# - 更改为通用接口(interface)对性能的影响

Question

我致力于使用 Visual Studio 在 C#/.NET 中开发应用程序。在我的方法原型(prototype)中，ReSharper 经常建议我将输入参数的类型替换为更通用的类型。例如，如果我只在我的方法主体中使用带有 foreach 的列表，则 List<> 和 IEnumerable<>。我能理解为什么这样写看起来更聪明，但我非常关心性能。如果我听 ReSharper，我担心我的应用程序的性能会下降...

有人能准确地(或多或少)向我解释当我写的时候幕后(即在 CLR 中)发生了什么吗:

public void myMethod(IEnumerable<string> list)
{
  foreach (string s in list)
  {
    Console.WriteLine(s);
  }
}

static void Main()
{
  List<string> list = new List<string>(new string[] {"a", "b", "c"});
  myMethod(list);
}

有什么区别:

public void myMethod(List<string> list)
{
  foreach (string s in list)
  {
    Console.WriteLine(s);
  }
}

static void Main()
{
  List<string> list = new List<string>(new string[] {"a", "b", "c"});
  myMethod(list);
}

Answer 1

您担心性能 - 但您有任何理由担心吗？我的猜测是您根本没有对代码进行基准测试。在用性能更高的代码替换可读、干净的代码之前，始终进行基准测试。

在这种情况下调用Console.WriteLine无论如何都会完全主导性能。

虽然我怀疑使用 List<T> 之间可能存在理论上的性能差异和 IEnumerable<T>在这里，我怀疑它在现实世界应用程序中具有重要意义的案例数量微乎其微。

它甚至不像序列类型被用于许多操作 - 有一个对 GetEnumerator() 的调用声明返回 IEnumerator<T>反正。随着列表变大，两者之间的任何性能差异将变得更更小，因为它只会在循环开始时产生任何影响。

虽然忽略了分析，但要从中提取的是测量性能，然后再根据它做出编码决策。

至于幕后发生的事情 - 您必须深入了解每种情况下元数据中的确切内容。我怀疑在接口(interface)的情况下有一个额外的重定向级别，至少在理论上是这样——CLR 必须计算出目标对象类型中 IEnumerable<T> 的 vtable 的位置。是，然后调入适当方法的代码。在List<T>的情况下，JIT 会知道从 vtable 开始的正确偏移量，而无需额外的查找。这只是基于我对 JITting、thunking、vtables 以及它们如何应用于接口(interface)的模糊理解。它可能有点错误，但更重要的是它是一个实现细节。