不要多余的演员得到优化? [英] Do redundant casts get optimized?

查看:127
本文介绍了不要多余的演员得到优化?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我更新一些旧代码,并发现那里的同一个对象被重复的施放每次都需要调用它的属性或方法之一多个实例。例如:

 如果(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;
}
,否则
{
(System.Windows.Forms.DateTimePicker)CTRL).CustomFormat =;
}
((System.Windows.Forms.DateTimePicker)CTRL).Format = DateTimePickerFormat.Custom;



我的倾向是解决这个庞然大物,但由于我的时间有限我不想打扰任何的不影响功能或性能。



所以我不知道是什么,在这些冗余的演员越来越被编译器优化掉?我试着用反汇编的一个简单的例子,但不熟悉与IL我只是结束了更加迷茫计算出来自己了。



更新



到目前为止,共识似乎是一个)没有,石膏不优化,但b)当有可能会有一些性能方面的提高,结果,它是不太可能显著,以及c)我应该考虑反正修复它们。我下来就解决哪天修复这些,如果我有时间的一面。同时,我也不会担心。



谢谢大家!


解决方案



<$:

这不是从IL在调试或发布版本优化掉



简单的C#测试p $ p> 使用系统;
使用System.Collections.Generic;
使用System.Linq的;
使用System.Text;

命名空间RedundantCastTest
{
类节目
{
静态对象的get()
{返回ASDF }

静态无效的主要(字串[] args)
{
obj对象= get()方法;
如果((字符串)OBJ ==ASDF)
Console.WriteLine(平等:{0},LEN:{1},OBJ,((字符串)OBJ)。长度);
}
}
}



对应的IL(注意多 castclass 指令):

 。方法私人hidebysig静态无效的主要(字串[]参数)CIL管理
{
.entrypoint
.maxstack 3
.locals的init(
[0] obj对象,
[1]布尔CS $ 4 $ 0000)
L_0000:NOP
L_0001:调用对象RedundantCastTest.Program ::得到()
L_0006:stloc.0
L_0007:ldloc.0
L_0008 :castclass字符串
L_000d:ldstrASDF
L_0012:拨打布尔[mscorlib程序] System.String :: op_Equality(字符串,字符串)
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平等:{0},LEN:{1}
L_0023:ldloc.0
L_0024:ldloc.0
L_0025:castclass字符串
L_002a:callvirt例如INT32 [mscorlib程序] System.String :: get_Length()
L_002f:箱INT32
L_0034:呼叫无效[mscorlib程序] System.Console:的WriteLine(字符串,对象,对象)
L_0039:NOP
L_003a:RET
}

无论是从IL在发布版本进行了优化:

 。方法私人hidebysig静态无效的主要(字串[] args)CIL管理
{
.entrypoint
.maxstack 3
.locals的init(
[0] obj对象)
L_0000:调用对象RedundantCastTest.Program ::得到()
L_0005:stloc.0
L_0006:ldloc.0
L_0007:castclass字符串
L_000c:ldstrASDF
L_0011:拨打布尔[mscorlib程序] System.String :: op_Equality(字符串,字符串)
L_0016:brfalse.s L_0033
L_0018:ldstr平等:{0},LEN:{1}
L_001d:ldloc.0
L_001e:ldloc.0
L_001f:castclass字符串
L_0024: callvirt例如INT32 [mscorlib程序] System.String :: get_Length()
L_0029:箱INT32
L_002e:呼叫无效[mscorlib程序] System.Console:的WriteLine(字符串,对象,对象)
L_0033:RET
}

无论情况,是指石膏不要让本机优化时代码生成 - 你需要在实际的机器看起来组装那里。即通过运行NGEN和拆卸。我大为吃惊,如果它没有被优化掉。



无论如何,我要举的 程序员修炼和破窗定理:当你看到一个破碎的窗户,修复它


I am updating some old code, and have found several instances where the same object is being cast repeatedly each time one of its properties or methods needs to be called. Example:

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;

My inclination is to fix this monstrosity, but given my limited time I don't want to bother with anything that's not affecting functionality or performance.

So what I'm wondering is, are these redundant casts getting optimized away by the compiler? I tried figuring it out myself by using ildasm on a simplified example, but not being familiar with IL I only ended up more confused.

UPDATE

So far, the consensus seems to be that a)no, the casts are not optimized, but b)while there may possibly be some small performance hit as a result, it is not likely significant, and c)I should consider fixing them anyway. I have come down on the side of resolving to fix these someday, if I have time. Meanwhile, I won't worry about them.

Thanks everyone!

解决方案

It is not optimized away from IL in either debug or release builds.

simple C# test:

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);
        }
    }
}

Corresponding IL (note the multiple castclass instructions):

.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 
}

Neither is it optimized from the IL in the release build:

.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 
}

Neither case means that the casts don't get optimized when native code is generated - you'd need to look at the actual machine assembly there. i.e. by running ngen and disassembling. I'd be greatly surprised if it wasn't optimized away.

Regardless, I'll cite The Pragmatic Programmer and the broken window theorem: When you see a broken window, fix it.

这篇关于不要多余的演员得到优化?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆