前言
.NET 3.5中新增的表达式树（Expression Tree）特性，第一次在.NET平台中引入了“逻辑即数据”的概念。也就是说，我们可以在代码里使用高级语言的形式编写一段逻辑，但是这段逻辑最终会被保存为数据。正因为如此，我们可以使用各种不同的方法对它进行处理。例如，您可以将其转化为一个SQL查询，或者外部服务调用等等，这便是LINQ to Everything在技术实现上的重要基石之一。
实事求是地说，.NET 3.5中的表达式树的能力较为有限，只能用来表示一个“表达式”，而不能表示“语句”。也就是说，我们可以用它来表示一次“方法调用”或“属性访问”，但不能用它来表示一段“逻辑”。不过，微软在.NET 4.0中增强了这一特性。在.NET 4.0中，我们可以使用表达式树构建一段带有“变量声明”，“判断”，“循环”的逻辑。当“逻辑”成为“数据”时，我们就拥有了更广阔的空间来发挥创造力。例如，我们可以将一段使用C#编写的顺序型逻辑，转化为包含异步调用的客户端JavaScript代码，以此快速构建带有复杂客户端逻辑的Web应用程序。
不过，即便是.NET 3.5中表达式树的“半吊子”特性，也已经显著加强了.NET平台的能力，甚至改变了我们对于一些事物的使用方式。
表达式树的优势
详见文章完整内容（链接）。
表达式树的计算
对表达式树进行计算，是处理表达式树时中最常见的工作了。几乎可以这么说，任何处理表达式树的工作都无法回避这个问题。在这里，“表达式树的计算”是指将一个复杂的表达式树转化为一个常量。例如，下图中左侧的表达式树，便可以转化为右侧的常量。
请注意，右侧的结果是一个常量，而不是一个ConstantExpression对象。当然，我们在必要的时候，也可以重新构造一个ConstantExpression对象，以便组成新的表达式树供后续分析。这个例子非常简单，而在实际的使用过程中遇到的表达式往往会复杂的多，他们可能包含“对象构造”、“下标访问”、“方法调用”、“属性读取”以及“?:”三目运算符等各种成员。它们的共同点，便是继承于Expression这一基类，并且最终都可以被计算为一个常量。
传统的表达式树的计算方式，是将其进行Compile为一个强类型的委托对象并加以执行，如下：
Expression<Func<DateTime>> expr = () => DateTime.Now.AddDays(1); Func<DateTime> tomorrow = expr.Compile(); Console.WriteLine(tomorrow());
如果是要计算一个类型不明确的表达式树，那么我们便需要要写一个通用的Eval方法，如下：
static object Eval(Expression expr) {LambdaExpression lambda = Expression.Lambda(expr);Delegate func = lambda.Compile();return func.DynamicInvoke(null); }static void Main(string[] args) {Expression<Func<DateTime>> expr = () => DateTime.Now.AddDays(1);Console.WriteLine(Eval(expr.Body)); }
简单说来，计算表达式树的通用方法会分三步走：
- 将表达式树封装在一个LambdaExpression对象
- 调用LambdaExpression的Compile方法动态生成一个委托对象
- 使用DynamicInvoke方法调用该委托对象，获取其返回值
Compile方法在内部使用了Emit，而DynamicInvoke方法其本质与反射调用差不多，因此这种通用的表达式计算方法会带来相对较为可观的开销。尤其是在某些场景中，很容易出现大量表达式树的计算操作。例如，在开发ASP.NET MVC应用程序的视图时，“最佳实践”之一便是使用支持表达式树的辅助方法来构造链接，例如：
<h2>Article List</h2><% foreach (var article in Model.Articles) { %> <div><%= Html.ActionLink<ArticleController>(c => c.Detail(article.ArticleID, 1), article.Title) %> <% for (var page = 2; page <= article.MaxPage; page++) { %> <small><%= Html.ActionLink<ArticleController>(c => c.Detail(article.ArticleID, page), page.ToString()) %> </small><% } %> </div> <% } %>
上述代码的作用，是在文章列表页上生成一系列指向文章详细页的链接。那么在上面的代码中，将会出现多少次表达式树的计算呢？
Html.ActionLink<ArticleController>(c => c.Detail(article.ArticleID, 1), article.Title)Html.ActionLink<ArticleController>(c => c.Detail(article.ArticleID, page), article.Title)
可以看出，每篇文章将进行(2 * MaxPage – 1)次计算，对于一个拥有数十篇文章的列表页，计算次数很可能逾百次。此外，再加上页面上的各种其它元素，如分类列表，Tag Cloud等等，每生成一张略为复杂的页面便会造成数百次的表达式树计算。从Simone Chiaretta的性能测试上来看，使用表达式树生成链接所花时间，大约为直接使用字符串的30倍。而根据我的本地测试结果，在一台P4 2.0 GHz的服务器上，单线程连续计算一万个简单的四则运算表达式便要花费超过1秒钟时间。这并非是一个可以忽略的性能开销，引入一种性能更好的表达式树计算方法势在必行。
减少Compile开销
详见文章完整内容（链接）。
减少反射开销
详见文章完整内容（链接）。
最后我们进行一个简单试验，将运算符数量为1-20的四则运算表达式各10个，分别计算1000次。三种实现耗时对比如下（请关注Normal和Fast的对比）：
FastEvaluator的主要开销在于从ExpressionCache中提取数据，它随着表达式的长度线性增加。拥有n个运算符的四则运算表达式树，其常量节点的数量为n + 1，因此总结节点数量为2n + 1。根据我的个人经验，项目中所计算的表达式树的节点数量一般都在10个以内。如图所示，在这个数据范围内，FastEvaluator的计算耗时仅为传统方法的1/20，并且随着节点数量的减少，两者差距进一步增大。此外，由于节省了反射调用的开销，即使在CacheEvaluator可以正常工作的范围内（1-3个运算符），FastEvaluator相对前者也有明显的性能提升。
总结
表达式树拥有语义清晰，强类型等诸多优势，可以预见，越来越多的项目会采取这种方式来改进自己的API。在这种情况下，表达式树的计算对于程序性能的影响也会越来越大。本文提出了一种表达式树计算操作的优化方式，将不同表达式树“标准化”为几种有限的结构，并复用其编译结果。由于减少了编译操作和反射操作的次数，表达式计算所需开销大大降低。
本文所有代码都公布于MSDN Code Gallary中的FastLambda项目中，您可以根据需要随意修改使用。此外，FastLambda项目中还包含了可以将表达式树的多个常量部分进行简化的组件（如将5 + 2 + 3 * 4 * x简化为7 + 12 * x），这对于处理原本就包含ParameterExpression的表达式树非常有用（如编写LINQ Provider时）。如果您对此感兴趣，可以关注项目中的PartialEvaluator和FastPartialEvaluator类，它们的区别在于前者利用Evaluator，而后者利用FastEvaluator进行表达式树的局部计算。
全文链接
本文已发表于InfoQ中文站，欢迎访问《快速计算表达式树》。
