[ C# ] 判断一个类是不是实现了某个接口的多种方法及性能分析

[ C# ] 判断一个类是否实现了某个接口的多种方法及性能分析

IEntity为一个接口,Entity为实现IEntity接口的类:

interface IEntity
{
    int Id { get; set; }
}

public class Entity : IEntity
{
    public int Id { get; set; }
    public string Prop { get; set; }
}

我们要判断Entity是否实现了IEntity接口,根据找到的帖子

c# 如何判断一个类是否实现了某个接口

在C#中判断某个类是否实现了某个接口

整理有如下五种方式:

1. 

Entity entity = new Entity();
if (entity is IEntity)
{
}

2.

Entity entity = new Entity();
IEntity temp = entity as IEntity;
if (temp != null)
{
}

3.

if (typeof(IEntity).IsAssignableFrom(typeof(Entity)))
{
}

4.

if (typeof(Entity).GetInterfaces().Contains(typeof(IEntity)))
{
}

5.

 if (typeof(Entity).GetInterface("IEntity")!=null)
 {
 }

但是我们知道,前2种方式要实例化Entity的新实例,后面三种方式要用到反射,这都是相对耗性能的操作!

那么这几种判断Entity是否实现了IEntity接口的方式哪一种相对来说对性能的消耗低呢?

我们让每个方法都执行1000万次:(以下测试均为Release 模式,.net framework 4.5.1框架)

Stopwatch stopwatch = null;
int count = 10000000;
Console.WriteLine("执行次数 {0}", count);

stopwatch = Stopwatch.StartNew();
for (int i = 0; i < count; i++)
{
    Entity entity = new Entity();
    if (entity is IEntity) { }
}
Console.WriteLine(stopwatch.Elapsed);

stopwatch = Stopwatch.StartNew();
for (int i = 0; i < count; i++)
{
    Entity entity = new Entity();
    IEntity temp = entity as IEntity;
    if (temp != null) { }
}
Console.WriteLine(stopwatch.Elapsed);

stopwatch = Stopwatch.StartNew();
for (int i = 0; i < count; i++)
{
    if (typeof(IEntity).IsAssignableFrom(typeof(Entity))) { }
}
Console.WriteLine(stopwatch.Elapsed);

stopwatch = Stopwatch.StartNew();
for (int i = 0; i < count; i++)
{
    if (typeof(Entity).GetInterfaces().Contains(typeof(IEntity))) { }
}
Console.WriteLine(stopwatch.Elapsed);

stopwatch = Stopwatch.StartNew();
for (int i = 0; i < count; i++)
{
    if (typeof(Entity).GetInterface("IEntity")!=null) { }
}
Console.WriteLine(stopwatch.Elapsed);

  测试结果:

[ C# ]   判断一个类是不是实现了某个接口的多种方法及性能分析

   执行1亿次的测试如下:

[ C# ]   判断一个类是不是实现了某个接口的多种方法及性能分析

可以看出使用了反射的后三种方式的性能消耗明显高于前两种方式。那么是不是结果一定是这样呢?

我们回到上面Entity类的定义发现,Entity类只有2个属性,而实例化Entity的主要开销是是根据类型所有字段的长度总和计算的。那么我们把Enity的属性增加到30个,每个方法执行1亿次的结果:

[ C# ]   判断一个类是不是实现了某个接口的多种方法及性能分析

这时发现使用了反射的后三种方式的性能消耗几乎没有变化,而有实例化操作的前两种方式所消耗的时间发生了成倍的增长!

我们继续增加Enity的属性到60个,每个方法执行1亿次的结果:

[ C# ]   判断一个类是不是实现了某个接口的多种方法及性能分析

继续增加Enity的属性到90个,每个方法执行1亿次的结果:

[ C# ]   判断一个类是不是实现了某个接口的多种方法及性能分析

当Entity类的属性到90的时候,实例化所需要的性能消耗已经远远超过两次typeof()所带来的性能消耗了。

最后我的结论是,在类和接口的属性/字段数量少的时候,判断某个类是否实现了某个接口,性能消耗依次是:方式2<方式1<方式3<方式4<方式5

        在类和接口的属性/字段相对较多的时候,判断某个类是否实现了某个接口,性能消耗依次是:方式3<方式2<方式1<方式4<方式5

那么为什么方式2的性能要优于方式1,就留给园友们来回答吧    demo下载

 

1楼失足程序员
我猜想应该是,is是判断,应该是也是基于反射的检查吧,as 是转化,没有过多的检查操作,个人意见
Re: Behavior
@失足程序员,嗯 。《clr via c#》中给出的答案是,is首先判断对象的实际类型,然后CLR遍历继承层次结构,用每个基类型去核对指定的对象类型。as 操作CLR只校验一次对象类型,如果类型不兼容,则as返回null