反射调用与Lambda表达式调用

想调用一个方法很容易，直接代码调用就行，这人人都会。其次呢，还可以使用反射。不过通过反射调用的性能会远远低于直接调用——至少从绝对时间上来看的确是这样。虽然这是个众所周知的现象，我们还是来写个程序来验证一下。比如我们现在新建一个Console应用程序，编写一个最简单的Call方法。

class Program
{
    static void Main(string[] args)
    {

    }

    public void Call(object o1, object o2, object o3) { }
}

Call方法接受三个object参数却没有任何实现，这样我们就可以让测试专注于方法调用，而并非方法实现本身。于是我们开始编写测试代码，比较一下方法的直接调用与反射调用的性能差距：

static void Main(string[] args)
{
    int times = 1000000;
    Program program = new Program();
    object[] parameters = new object[] { new object(), new object(), new object() };
    program.Call(null, null, null); // force JIT-compile

    Stopwatch watch1 = new Stopwatch();
    watch1.Start();
    for (int i = 0; i < times; i++)
    {
        program.Call(parameters[0], parameters[1], parameters[2]);
    }
    watch1.Stop();
    Console.WriteLine(watch1.Elapsed + " (Directly invoke)");

    MethodInfo methodInfo = typeof(Program).GetMethod("Call");
    Stopwatch watch2 = new Stopwatch();
    watch2.Start();
    for (int i = 0; i < times; i++)
    {
        methodInfo.Invoke(program, parameters);
    }
    watch2.Stop();
    Console.WriteLine(watch2.Elapsed + " (Reflection invoke)");

    Console.WriteLine("Press any key to continue...");
    Console.ReadKey();
}

执行结果如下：

00:00:00.0119041 (Directly invoke)
00:00:04.5527141 (Reflection invoke)
Press any key to continue...

通过各调用一百万次所花时间来看，两者在性能上具有数量级的差距。因此，很多框架在必须利用到反射的场景中，都会设法使用一些较高级的替代方案来改善性能。例如，使用CodeDom生成代码并动态编译，或者使用Emit来直接编写IL。不过自从.NET 3.5发布了Expression相关的新特性，我们在以上的情况下又有了更方便并直观的解决方案。

了解Expression相关特性的朋友可能知道，System.Linq.Expressions.Expression<TDelegate>类型的对象在调用了它了Compile方法之后将得到一个TDelegate类型的委托对象，而调用一个委托对象与直接调用一个方法的性能开销相差无几。那么对于上面的情况，我们又该得到什么样的Delegate对象呢？为了使解决方案足够通用，我们必须将各种签名的方法统一至同样的委托类型中，如下：

public Func<object, object[], object> GetVoidDelegate()
{
    Expression<Action<object, object[]>> exp = (instance, parameters) =>
        ((Program)instance).Call(parameters[0], parameters[1], parameters[2]);

    Action<object, object[]> action = exp.Compile();
    return (instance, parameters) =>
    {
        action(instance, parameters);
        return null;
    };
}

如上，我们就得到了一个Func<object, object[], object>类型的委托，这意味它接受一个object类型与object[]类型的参数，以及返回一个object类型的结果——等等，朋友们有没有发现，这个签名与MethodInfo类型的Invoke方法完全一致？不过可喜可贺的是，我们现在调用这个委托的性能远高于通过反射来调用了。那么对于有返回值的方法呢？那构造一个委托对象就更方便了：

public int Call(object o1, object o2) { return 0; }

public Func<object, object[], object> GetDelegate()
{
    Expression<Func<object, object[], object>> exp = (instance, parameters) =>
        ((Program)instance).Call(parameters[0], parameters[1]);

    return exp.Compile();
}

至此，我想朋友们也已经能够轻松得出调用静态方法的委托构造方式了。可见，这个解决方案的关键在于构造一个合适的Expression<TDelegate>，那么我们现在就来编写一个DynamicExecuter类来作为一个较为完整的解决方案：

public class DynamicMethodExecutor
{
    private Func<object, object[], object> m_execute;

    public DynamicMethodExecutor(MethodInfo methodInfo)
    {
        this.m_execute = this.GetExecuteDelegate(methodInfo);
    }

    public object Execute(object instance, object[] parameters)
    {
        return this.m_execute(instance, parameters);
    }

    private Func<object, object[], object> GetExecuteDelegate(MethodInfo methodInfo)
    {
        // parameters to execute
        ParameterExpression instanceParameter =
            Expression.Parameter(typeof(object), "instance");
        ParameterExpression parametersParameter =
            Expression.Parameter(typeof(object[]), "parameters");

        // build parameter list
        List<Expression> parameterExpressions = new List<Expression>();
        ParameterInfo[] paramInfos = methodInfo.GetParameters();
        for (int i = 0; i < paramInfos.Length; i++)
        {
            // (Ti)parameters[i]
            BinaryExpression valueObj = Expression.ArrayIndex(
                parametersParameter, Expression.Constant(i));
            UnaryExpression valueCast = Expression.Convert(
                valueObj, paramInfos[i].ParameterType);

            parameterExpressions.Add(valueCast);
        }

        // non-instance for static method, or ((TInstance)instance)
        Expression instanceCast = methodInfo.IsStatic ? null :
            Expression.Convert(instanceParameter, methodInfo.ReflectedType);

        // static invoke or ((TInstance)instance).Method
        MethodCallExpression methodCall = Expression.Call(
            instanceCast, methodInfo, parameterExpressions);

        // ((TInstance)instance).Method((T0)parameters[0], (T1)parameters[1], ...)
        if (methodCall.Type == typeof(void))
        {
            Expression<Action<object, object[]>> lambda =
                Expression.Lambda<Action<object, object[]>>(
                    methodCall, instanceParameter, parametersParameter);

            Action<object, object[]> execute = lambda.Compile();
            return (instance, parameters) =>
            {
                execute(instance, parameters);
                return null;
            };
        }
        else
        {
            UnaryExpression castMethodCall = Expression.Convert(
                methodCall, typeof(object));
            Expression<Func<object, object[], object>> lambda =
                Expression.Lambda<Func<object, object[], object>>(
                    castMethodCall, instanceParameter, parametersParameter);

            return lambda.Compile();
        }
    }
}

DynamicMethodExecutor的关键就在于GetExecuteDelegate方法中构造Expression Tree的逻辑。如果您对于一个Expression Tree的结构不太了解的话，不妨尝试一下使用Expression Tree Visualizer来对一个现成的Expression Tree进行观察和分析。我们将一个MethodInfo对象传入DynamicMethodExecutor的构造函数之后，就能将各组不同的实例对象和参数对象数组传入Execute进行执行。这一切就像使用反射来进行调用一般，不过它的性能就有了明显的提高。例如我们添加更多的测试代码：

DynamicMethodExecutor executor = new DynamicMethodExecutor(methodInfo);
Stopwatch watch3 = new Stopwatch();
watch3.Start();
for (int i = 0; i < times; i++)
{
    executor.Execute(program, parameters);
}
watch3.Stop();
Console.WriteLine(watch3.Elapsed + " (Dynamic executor)");

现在的执行结果则是：

00:00:00.0125539 (Directly invoke)
00:00:04.5349626 (Reflection invoke)
00:00:00.0322555 (Dynamic executor)
Press any key to continue...

事实上，Expression<TDelegate>类型的Compile方法正是使用Emit来生成委托对象。不过现在我们已经无需将目光放在更低端的IL上，只要使用高端的API来进行Expression Tree的构造，这无疑是一种进步。不过这种方法也有一定局限性，例如我们只能对公有方法进行调用，并且包含out/ref参数的方法，或者除了方法外的其他类型成员，我们就无法如上例般惬意地编写代码了。

补充

木野狐兄在评论中引用了Code Project的文章《A General Fast Method Invoker》，其中通过Emit构建了FastInvokeHandler委托对象（其签名与Func<object, object[], object>完全相同）的调用效率似乎较“方法直接”调用的性能更高（虽然从原文示例看来并非如此）。事实上FastInvokeHandler其内部实现与DynamicMethodExecutor完全相同，居然有如此令人不可思议的表现实在让人啧啧称奇。我猜测，FastInvokeHandler与DynamicMethodExecutor的性能优势可能体现在以下几个方面：

  1. 范型委托类型的执行性能较非范型委托类型略低（求证）。
  2. 多了一次Execute方法调用，损失部分性能。
  3. 生成的IL代码更为短小紧凑。
  4. 木野狐兄没有使用Release模式编译。:P

不知道是否有对此感兴趣的朋友能够再做一个测试，不过请注意此类性能测试一定需要在Release编译下进行（这点很容易被忽视），否则意义其实不大。

此外，我还想强调的就是，本篇文章进行是纯技术上的比较，并非在引导大家追求点滴性能上的优化。有时候看到一些关于比较for或foreach性能优劣的文章让许多朋友都纠结与此，甚至搞得面红耳赤，我总会觉得有些无可奈何。其实从理论上来说，提高性能的方式有许许多多，记得当时在大学里学习Introduction to Computer System这门课时得一个作业就是为一段C程序作性能优化，当时用到不少手段，例如内联方法调用以减少CPU指令调用次数、调整循环嵌套顺序以提高CPU缓存命中率，将一些代码使用内嵌ASM替换等等，可谓“无所不用其极”，大家都在为几个时钟周期的性能提高而发奋图强欢呼雀跃……

那是理论，是在学习。但是在实际运用中，我们还必须正确对待学到的理论知识。我经常说的一句话是：“任何应用程序都会有其性能瓶颈，只有从性能瓶颈着手才能做到事半功倍的结果。”例如，普通Web应用的性能瓶颈往往在外部IO（尤其是数据库读写），要真正提高性能必须从此入手（例如数据库调优，更好的缓存设计）。正因如此，开发一个高性能的Web应用程序的关键不会在语言或语言运行环境上，.NET、RoR、PHP、Java等等在这一领域都表现良好。

反射调用与Lambda表达式调用

时间： 2024-10-20 12:37:25

反射调用与Lambda表达式调用的相关文章

推迟调用以及Lambda表达式

背景 GMock 我们项目中现在的模块测试框架使用了CATCH+GMock的方式实现回归测试和打桩. GMock的介绍在官网上有,这里为了铺垫,大概地描述一下GMock能实现的效果.大约可以看成这样: void A() { ????if(B()) { ????????//... ????} ????Else{ ????????//... ????} } A是被测函数,B是桩函数. 在测试的,使用GMock的话,我们可以这样写测试代码: TEST_CASE(Test As normal case)

C#中分别对委托、匿名方法、Lambda表达式、Lambda表达式树以及反射执行同一方法的过程进行比较。

using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using System.Reflection; using System.Linq.Expressions; namespace INPEXOne.LearnCS { class RefletLambdaDelegate { static object[] para

Java8新增的Lambda表达式

Lambda表达式支持将代码块作为方法参数,Lambda表达式允许使用更简单的代码来创建只有一个抽象方法的接口(这种接口被称为函数式接口)的实例. 5.8.1 Lambda 表达式入门 Command.java package code; public interface Command { // 接口里定义的process()方法用于封装"处理行为" void process(int[] target); } ProcessArray.java package code; publi

Lambda表达式和Lambda表达式树

LINQ的基本功能就是创建操作管道,以及这些操作需要的任何状态. 为了富有效率的使用数据库和其他查询引擎,我们需要一种不同的方式表示管道中的各个操作.即把代码当作可在编程中进行检查的数据. Lambda表达式不仅可以用他们创建委托实例,而且C#编译器也能将他们转换成表达式树——用于表示Lambda表达式逻辑的一种数据结构.简言之——Lambda表达式用符号语言习惯的方法来表示LINQ数据管线中的操作. 作为委托的Lambda表达式 Lambda有特殊转换规则:表达式的类型本身并非委托类型,但它可

Lambda 表达式的演示样例-来源(MSDN)

本文演示怎样在你的程序中使用 lambda 表达式. 有关 lambda 表达式的概述.请參阅 C++ 中的 Lambda 表达式. 有关 lambda 表达式结构的具体信息,请參阅 Lambda 表达式语法. 本文内容 声明 Lambda 表达式 调用 Lambda 表达式 嵌套 Lambda 表达式 高阶 Lambda 函数 在函数中使用 Lambda 表达式 配合使用 Lambda 表达式和模板 处理异常 配合使用 Lambda 表达式和托管类型 声明 Lambda 表达式 演示样例 1

Lambda表达式的本质是匿名函数

1.委托的简介: 委托可以简单的理解为方法的列表,添加的方法的参数类型,个数,顺序必须和委托一致, 也就是说委托起到了托管方法的作用,并且约束了要调用的方法. 1 //1声明委托 2 public delegate void NoReturnNoPara(); 3 public delegate void NoReturnWithPara(string name, int id); 4 public delegate int WithReturnNoPara(); 5 public delega

Lambda 表达式的示例-来源(MSDN)

本文演示如何在你的程序中使用 lambda 表达式. 有关 lambda 表达式的概述,请参阅 C++ 中的 Lambda 表达式. 有关 lambda 表达式结构的详细信息,请参阅 Lambda 表达式语法. 本文内容 声明 Lambda 表达式 调用 Lambda 表达式 嵌套 Lambda 表达式 高阶 Lambda 函数 在函数中使用 Lambda 表达式 配合使用 Lambda 表达式和模板 处理异常 配合使用 Lambda 表达式和托管类型 声明 Lambda 表达式 示例 1 由于

C++11新特性(3) lambda表达式(1)

C++11添加了一项名为lambda表达式的新功能.通过这项功能能编写内嵌的匿名函数,而不必编写独立函数或函数对象,使得代码更加理解. lambda表达式包含以下部分. [capture_block](parameters) mutable exception_specification->return_type {body} 现在分析各个部分的内容: (capture_block)捕捉块:指定如何捕捉所在作用域的变量,并供给lambda主体部分使用. (parameter)参数(可选):lam

Lambda 表达式的示例

本文中的过程演示如何使用 lambda 表达式. Lambda Expressions in C++.' data-guid="411656d77b666e51e15caac8de528191">有关 lambda 表达式的概述,请参见 C++ 中的 Lambda 表达式. Lambda Expression Syntax.' data-guid="df40a218a0617e5e01e20ad28527a334">有关 lambda 表达式结构的更多信