考虑对集合进行以下简单操作：
static List<int> x = new List<int>() { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
var result = x.Where(i => i % 2 == 0).Where(i => i > 5);
现在让我们使用表达式。以下代码大致等效：
static void UsingLambda() {
Func<IEnumerable<int>, IEnumerable<int>> lambda = l => l.Where(i => i % 2 == 0).Where(i => i > 5);
var t0 = DateTime.Now.Ticks;
for (int j = 1; j < MAX; j++)
var sss = lambda(x).ToList();
var tn = DateTime.Now.Ticks;
Console.WriteLine("Using lambda: {0}", tn - t0);
}
但是我想即时构建表达式，所以这是一个新测试：
static void UsingCompiledExpression() {
var f1 = (Expression<Func<IEnumerable<int>, IEnumerable<int>>>)(l => l.Where(i => i % 2 == 0));
var f2 = (Expression<Func<IEnumerable<int>, IEnumerable<int>>>)(l => l.Where(i => i > 5));
var argX = Expression.Parameter(typeof(IEnumerable<int>), "x");
var f3 = Expression.Invoke(f2, Expression.Invoke(f1, argX));
var f = Expression.Lambda<Func<IEnumerable<int>, IEnumerable<int>>>(f3, argX);
var c3 = f.Compile();
var t0 = DateTime.Now.Ticks;
for (int j = 1; j < MAX; j++)
var sss = c3(x).ToList();
var tn = DateTime.Now.Ticks;
Console.WriteLine("Using lambda compiled: {0}", tn - t0);
}
当然，它与上面的不完全一样，因此，公平地说，我对第一个做些微修改：
static void UsingLambdaCombined() {
Func<IEnumerable<int>, IEnumerable<int>> f1 = l => l.Where(i => i % 2 == 0);
Func<IEnumerable<int>, IEnumerable<int>> f2 = l => l.Where(i => i > 5);
Func<IEnumerable<int>, IEnumerable<int>> lambdaCombined = l => f2(f1(l));
var t0 = DateTime.Now.Ticks;
for (int j = 1; j < MAX; j++)
var sss = lambdaCombined(x).ToList();
var tn = DateTime.Now.Ticks;
Console.WriteLine("Using lambda combined: {0}", tn - t0);
}
现在得出MAX = 100000，VS2008的结果，调试打开：
Using lambda compiled: 23437500
Using lambda: 1250000
Using lambda combined: 1406250
并通过调试关闭：
Using lambda compiled: 21718750
Using lambda: 937500
Using lambda combined: 1093750
惊喜。编译的表达式比其他表达式慢大约17倍。现在出现了问题：
- 我在比较非对等表达式吗？
- 是否存在使.NET“优化”编译表达式的机制？
- 如何以
l.Where(i => i % 2 == 0).Where(i => i > 5);编程方式表达相同的连锁电话？
一些更多的统计数据。Visual Studio 2010，调试打开，优化关闭：
Using lambda: 1093974
Using lambda compiled: 15315636
Using lambda combined: 781410
调试打开，优化打开：
Using lambda: 781305
Using lambda compiled: 15469839
Using lambda combined: 468783
调试关闭，优化打开：
Using lambda: 625020
Using lambda compiled: 14687970
Using lambda combined: 468765
新惊喜。从VS2008（C＃3）切换到VS2010（C＃4），UsingLambdaCombined比本地Lambda更快。
好的，我找到了一种将lambda编译性能提高一个数量级以上的方法。这是一个提示；运行探查器后，有92％的时间用于：
System.Reflection.Emit.DynamicMethod.CreateDelegate(class System.Type, object)嗯...为什么要在每次迭代中创建一个新的委托？我不确定，但是解决方案将在另一篇文章中介绍。
我不知道为什么它要慢一些，但是您的基准测试技术不是很好。首先，DateTime.Now仅精确到1/64秒，因此您的测量舍入误差很大。改用秒表；精确到几纳秒。其次，您正在测量启动代码（第一个调用）和每个后续调用的时间。可能会偏离平均值。（尽管在这种情况下，十万的最大值可能足以平均消除jit负担，但是，将其平均包括在内是一种不好的做法。）
—
Eric Lippert
@Eric，只有在每个操作中使用DateTime.Now.Ticks时，才存在舍入错误，在开始之前和结束之后，毫秒计数足够高以显示性能差异。
—
Akash Kava
如果使用秒表，我建议您遵循以下文章以确保准确的结果：codeproject.com/KB/testing/stopwatch-measure-precise.aspx
—
Zach Green
@Eric，虽然我同意这不是可用的最精确的测量技术，但我们正在谈论的是一个数量级的差异。MAX足够高，可以减少明显的偏差。
—
Hugo Sereno Ferreira
Stopwatch用于计时而不是DateTime.Now。