c# - 接口(interface)转换与类转换

Question

我一直相信，在某些情况下，转换会成为性能的可衡量障碍。当我们开始处理令人讨厌的异常抛出\捕获的不连贯网络时，情况可能更是如此。

鉴于我希望在编程方面创建更正确的启发式方法，系统提示我向那里的 .NET 专家提出这个问题:接口(interface)转换是否比类转换更快？

举个代码例子，假设这个存在:

public interface IEntity { IParent DaddyMommy { get; } }
public interface IParent : IEntity { }
public class Parent : Entity, IParent { }
public class Entity : IEntity
{
    public IParent DaddyMommy { get; protected set; }
    public IParent AdamEve_Interfaces
    {
        get
        {
            IEntity e = this;
            while (e.DaddyMommy != null)
                e = e.DaddyMommy as IEntity;
            return e as IParent;
        }   
    }
    public Parent AdamEve_Classes
    {
        get
        {
            Entity e = this;
            while (e.DaddyMommy != null)
                e = e.DaddyMommy as Entity;
            return e as Parent;
        }
    }
}

那么，AdamEve_Interfaces 比 AdamEve_Classes 快吗？如果是这样，增加多少？而且，如果您知道答案，为什么？

Answer 1

这里的许多答案都建议进行基准测试，这是朝着正确方向迈出的一步，但只是旅程的第一步。

我的团队在这方面做了很多分析和基准测试。简短的版本是是的，在某些情况下，接口(interface)会带来很小但可衡量的性能成本。 但是实际成本取决于很多因素，包括支持的接口(interface)数量、给定引用转换到的接口(interface)数量、访问模式等。 CLR 有很多启发式方法，旨在加速常见情况下的接口(interface)访问。

如果您正在对其中一种常见情况进行基准测试，但您的实际程序属于不太常见的情况，那么您的基准测试非常有害，因为它提供的数据具有误导性。

对真实 代码进行实际性能测量要好得多。使用探查器，以两种方式编写代码，并查看任何一种方式是否以用户可见且相关的方式可测量、可重复地更快。

至于你提到的throw and catching:throw和catch的性能开销应该是无关紧要的。根据定义，异常(exception)是特殊的，而不是常见的。此外，异常通常表示某些事情即将停止；事情是否尽快停止通常并不重要。如果您的性能受到异常的限制，那么您有更大的问题需要解决:停止抛出这么多异常。抛出的异常应该是极其罕见的。