C# 编译器不会优化不必要的强制转换

Question

几天前，在溢出时为这个问题写答案时，我C# 编译器让我有点惊讶，它没有按照我的预期去做。查看以下代码片段：

第一：

object[] array = new object[1];

for (int i = 0; i < 100000; i++)
{
    ICollection<object> col = (ICollection<object>)array;
    col.Contains(null);
}

第二：

object[] array = new object[1];

for (int i = 0; i < 100000; i++)
{
    ICollection<object> col = array;
    col.Contains(null);
}

两个代码片段之间的唯一区别是转换为 ICollection

比较两个片段中的 IL 后，我注意到这两种方法是相同的，除了第一个片段中的 castclass IL 指令。

对此感到惊讶，我现在想知道为什么 C# 编译器在这里不“智能”。事情从来没有看起来那么简单，那么为什么 C# 编译器在这里有点幼稚呢？

Answer 1

我的猜测是您在优化器中发现了一个小错误。其中有数组的各种特殊情况代码。感谢您引起我的注意。

Answer 2

这是一个粗略的猜测，但我认为这是关于数组与其通用 IEnumerable 的关系。

在 .NET Framework 2.0 版中，
数组类实现了
System.Collections.Generic.IList，
System.Collections.Generic.ICollection，
和
System.Collections.Generic.IEnumerable
通用接口。这
提供给数组的实现
在运行时，因此不是
对文档构建可见
工具。结果，通用的
界面中没有出现
数组的声明语法
类，并且没有参考
接口成员的主题是
只能通过将数组转换为
通用接口类型（显式
接口实现）。关键
当你施放时要注意的事情
这些接口之一的数组是
添加、插入或
删除元素抛出
NotSupportedException。

请参阅 MSDN 文章。

目前尚不清楚这是否与 .NET 2.0+ 有关，但在这种特殊情况下，如果表达式仅在运行时有效，那么编译器无法优化表达式的原因就很明显了。

Answer 3

这看起来只不过是编译器错过了抑制强制转换的机会。如果你这样写它就会起作用：

    ICollection<object> col = array as ICollection<object>;

这表明它变得过于保守，因为强制转换可能会引发异常。但是，当您转换为非泛型 ICollection 时，它确实有效。我的结论是他们只是忽略了这一点。

这里有一个更大的优化问题，JIT 编译器不应用循环不变提升优化。它应该像这样重写代码：

object[] array = new object[1];
ICollection<object> col = (ICollection<object>)array;
for (int i = 0; i < 100000; i++)
{
    col.Contains(null);
}

例如，这是 C/C++ 代码生成器中的标准优化。尽管如此，JIT 优化器无法在发现此类可能的优化所需的分析上消耗大量周期。令人高兴的是，优化的托管代码仍然是相当可调试的。 C# 程序员仍然可以编写高性能代码。