冗余的转换是否得到优化？

Question

我正在更新一些旧代码，并且发现了几个实例，其中每次需要调用同一对象的属性或方法之一时都会重复转换该对象。示例：

if (recDate != null && recDate > ((System.Windows.Forms.DateTimePicker)ctrl).MinDate)
{
    ((System.Windows.Forms.DateTimePicker)ctrl).CustomFormat = "MM/dd/yyyy";
    ((System.Windows.Forms.DateTimePicker)ctrl).Value = recDate;
}
else
{
    (System.Windows.Forms.DateTimePicker)ctrl).CustomFormat = " ";
}
((System.Windows.Forms.DateTimePicker)ctrl).Format = DateTimePickerFormat.Custom;

我倾向于修复这个怪物，但考虑到我的时间有限，我不想打扰任何不影响功能或性能的事情。

所以我想知道的是，这些冗余的转换是否被编译器优化掉了？我尝试通过在一个简化的示例中使用 ildasm 来自己解决这个问题，但由于不熟悉 IL，我最终变得更加困惑。

更新

到目前为止，共识似乎是：a) 不，转换未优化，但是 b) 虽然结果可能会产生一些小的性能影响，但不太可能显着，并且c) 无论如何我应该考虑修复它们。如果我有时间的话，我决心有一天解决这些问题。与此同时，我不会担心他们。

谢谢大家！

Answer 1

对发布版本中生成的机器代码进行抽查表明，x86 抖动并未优化丢弃。

不过，你必须放眼全局。您正在分配控件的属性。它们有很多副作用。对于 DateTimePicker，分配结果会导致一条消息发送到本机 Windows 控件。这反过来又对这条消息进行了处理。与副作用的成本相比，演员的成本可以忽略不计。重写作业永远不会对速度产生明显的影响，你只会让它快一点点。

继续在一个慵懒的周五下午重写代码吧。但这只是因为它损害了可读性。可读性差的 C# 代码也会产生优化不佳的机器代码，这并不完全是巧合。

Answer 2

无论是在调试还是发布版本中，它都没有针对 IL 进行优化。

简单的 C# 测试：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace RedundantCastTest
{
    class Program
    {
        static object get()
        { return "asdf"; }

        static void Main(string[] args)
        {
            object obj = get();
            if ((string)obj == "asdf")
                Console.WriteLine("Equal: {0}, len: {1}", obj, ((string)obj).Length);
        }
    }
}

相应的 IL（注意多个 castclass 指令）：

.method private hidebysig static void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack 3
    .locals init (
        [0] object obj,
        [1] bool CS$4$0000)
    L_0000: nop 
    L_0001: call object RedundantCastTest.Program::get()
    L_0006: stloc.0 
    L_0007: ldloc.0 
    L_0008: castclass string
    L_000d: ldstr "asdf"
    L_0012: call bool [mscorlib]System.String::op_Equality(string, string)
    L_0017: ldc.i4.0 
    L_0018: ceq 
    L_001a: stloc.1 
    L_001b: ldloc.1 
    L_001c: brtrue.s L_003a
    L_001e: ldstr "Equal: {0}, len: {1}"
    L_0023: ldloc.0 
    L_0024: ldloc.0 
    L_0025: castclass string
    L_002a: callvirt instance int32 [mscorlib]System.String::get_Length()
    L_002f: box int32
    L_0034: call void [mscorlib]System.Console::WriteLine(string, object, object)
    L_0039: nop 
    L_003a: ret 
}

它也没有从发布版本中的 IL 进行优化：

.method private hidebysig static void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack 3
    .locals init (
        [0] object obj)
    L_0000: call object RedundantCastTest.Program::get()
    L_0005: stloc.0 
    L_0006: ldloc.0 
    L_0007: castclass string
    L_000c: ldstr "asdf"
    L_0011: call bool [mscorlib]System.String::op_Equality(string, string)
    L_0016: brfalse.s L_0033
    L_0018: ldstr "Equal: {0}, len: {1}"
    L_001d: ldloc.0 
    L_001e: ldloc.0 
    L_001f: castclass string
    L_0024: callvirt instance int32 [mscorlib]System.String::get_Length()
    L_0029: box int32
    L_002e: call void [mscorlib]System.Console::WriteLine(string, object, object)
    L_0033: ret 
}

这两种情况都意味着生成本机代码时不会优化转换 -你需要看看那里的实际机器组装。即通过运行 ngen 并反汇编。如果它没有被优化掉，我会感到非常惊讶。

无论如何，我会引用实用程序员和破窗定理：当你看到窗户坏了，就把它修好。

Answer 3

不; FxCop 将此标记为性能警告。请参阅此处的信息：http://msdn.microsoft.com/en-us/library /ms182271.aspx

如果您想找到需要修复的问题，我建议您在代码上运行它。

Answer 4

我从未听说过或见过 CLR 上的冗余转换优化。让我们尝试一个人为的示例

object number = 5;
int iterations = 10000000;
int[] storage = new int[iterations];

var sw = Stopwatch.StartNew();
for (int i = 0; i < iterations; i++) {
    storage[i] = ((int)number) + 1;
    storage[i] = ((int)number) + 2;
    storage[i] = ((int)number) + 3;
}
Console.WriteLine(sw.ElapsedTicks);

storage = new int[iterations];

sw = Stopwatch.StartNew();
for (int i = 0; i < iterations; i++) {
    var j = (int)number;
    storage[i] = j + 1;
    storage[i] = j + 2;
    storage[i] = j + 3;
}
Console.WriteLine(sw.ElapsedTicks);
Console.ReadLine();

，在我的机器上，在发布版本下运行，我始终获得大约 350k 滴答声用于冗余冗余和 280k 滴答声用于自我优化。所以不，看起来 CLR 没有对此进行优化。