优化通过表达式树构造URL的性能
2009-09-01 19:29 by 老赵, 5483 visits我们继续改进通过表达式树构造URL的方式。在上一篇文章中,辅助方法可以正确地识别了ActionNameAttribute,而这次改进的则是性能方面的问题。首先还是来看一下用于从表达式树获取RouteValueDictionary的方法:
public static RouteValueDictionary GetRouteValues<TController>( Expression<Action<TController>> action) where TController : Controller { ... var rvd = new RouteValueDictionary(); rvd.Add("controller", controllerName); rvd.Add("action", GetActionName(call.Method)); AddParameterValues(rvd, call); return rvd; } private static void AddParameterValues( RouteValueDictionary rvd, MethodCallExpression call) { ParameterInfo[] parameters = call.Method.GetParameters(); for (int i = 0; i < parameters.Length; i++) { Expression arg = call.Arguments[i]; object value = null; ConstantExpression ce = arg as ConstantExpression; if (ce != null) { // If argument is a constant expression, just get the value value = ce.Value; } else { // Otherwise, convert the argument subexpression to type object, // make a lambda out of it, compile it, and invoke it to get the value Expression<Func<object>> lambdaExpression = Expression.Lambda<Func<object>>( Expression.Convert(arg, typeof(object))); Func<object> func = lambdaExpression.Compile(); value = func(); } rvd.Add(parameters[i].Name, value); } }
这次我们关注的是第二个方法AddParameterValues。这个方法的目的是从表示action调用的表达式树(它是一个MethodCallExpression)中提取所有的参数——也是一个一个表达式树,并将它们表示的“值”填充到RouteValueDictionary中。这段代码使用了传统计算一个表达式树的方式:“使用LambdaExpression对象封装,再编译,最后执行”来获得一个Expression对象的值。但是,Compile方法的性能是比较低下的,如果密集地执行会对性能产生一定影响。
那么,您认为在ASP.NET MVC的场景中,Compile方法的执行频率如何呢?请想象一下这样的一个场景:
<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秒钟时间。这并非是一个可以忽略的性能开销,引入一种性能更好的表达式树计算方法势在必行。
在《快速计算表达式树》一文中,我已经对这一话题进行了非常深入的探讨(甚至还可以算上表达式树的缓存这一系列文章),并最终给出了一个可以直接复用的解决方案:FastLambda。因此,我们在这里只需要使用如下的方式来改进表达式树的“计算”方式即可:
private static void AddParameterValues( RouteValueDictionary rvd, MethodCallExpression call) { ParameterInfo[] parameters = call.Method.GetParameters(); for (int i = 0; i < parameters.Length; i++) { rvd.Add(parameters[i].Name, Eval(call.Arguments[i])); } } private static FastEvaluator s_parameterEvaluator = new FastEvaluator(); private static object Eval(Expression exp) { ConstantExpression ce = exp as ConstantExpression; if (ce != null) return ce.Value; return s_parameterEvaluator.Eval(exp); }
FastEvaluator是FastLambda项目中提供的一个类,它会对输入的表达式树进行分析,并根据其结构缓存编译后的结果,于是下次输入结构相同的表达式时,便可以快速的计算出结果,省去了编译的开销。例如在上面的例子中,无论article指向的是什么对象,无论page的值是多少,article.ArticleID或page本身的结构永远是不变的。因此,对于刚才的例子,无论访问了多少次页面,作了多少次循环,都只会进行两次编译。此外,由于FastEvaluator已经实现为一个线程安全的组件,因此这里我们只须直接使用即可,无需进行太多考虑。
那么,这么做会带来多少性能提升呢?请看如下的示意图:
这幅图表达的是在计算拥有2n + 1个节点的表达式树时,普通的做法(红线)与FastEvaluator(紫线)的性能差距。根据我的个人经验,项目中所计算的表达式树的节点数量一般都在10个以内。如图所示,在这个数据范围内,FastEvaluator的计算耗时仅为传统方法的1/20。对于刚才的示例来说,节点数量为3或5,则表示n为1或3,在这种节点数量极少的情况下,性能的差距甚至可以达到50至100倍。
当然,一个应用程序的性能不是由这么简单的一个细节决定的,但是现在我们为一个较为频繁的操作进行了非常明显的性能优化。更重要的是,我们并没有因此损失任何易用性。因此,如果您在ASP.NET MVC中通过表达式树构造URL的话,我建议您使用现在的方案进行改进。
至于FastEvaluator组件的原理及实现等细节内容,还请参考我写的《快速计算表达式树》一文。
写的天书呢?看不懂