简单Lambda表达式与本地函数赋值给委托的性能差异探究

好问题！咱们来仔细拆解你提到的这个场景——在没有捕获外部变量、非递归、非泛型、非迭代器的简单情况下，用Lambda表达式和本地函数给Enumerable.ToLookup传递键选择器，到底有没有差异。

核心性能差异：委托实例的创建 #

你提到svick说Lambda需要创建委托而本地函数不需要，但这里因为我们要把函数传递给ToLookup（它接受一个Func<TSource, TKey>委托参数），所以两种方式最终都会生成委托实例。那关键问题是：编译器会不会每次调用ToLookup都为Lambda创建新委托？

答案是：在无变量捕获的场景下，Lambda和本地函数的委托实例都会被编译器静态缓存。也就是说，第一次调用时创建委托实例，后续调用都会复用同一个实例，不会重复分配内存。

• 对于Lambda：编译器会生成一个静态字段来存储委托实例，每次调用时直接返回这个缓存的实例，不会重新创建。
• 对于本地函数：同理，对应的委托实例也会被静态缓存，和Lambda的处理逻辑一致。

所以在委托实例的创建开销上，二者没有性能差异。

方法调用的性能 #

在IL层面，无捕获的Lambda会被编译成一个静态匿名方法，本地函数也会被编译成静态方法（因为不需要访问外部变量）。调用这两种方法的开销完全一致——没有额外的闭包开销，也没有性能损耗。

非性能差异：调试与可读性 #

虽然性能上没差别，但有两个实用层面的差异：

• 调试体验：本地函数有明确的名称（比如你的ByName），调试时调用栈里会显示这个名字，更容易追踪代码执行；而Lambda生成的匿名方法名字是编译器自动生成的（类似<YourMethodName>b__0_0），可读性差很多。
• 代码可读性：如果键选择逻辑稍微复杂一点，本地函数的命名能让代码意图更清晰；Lambda适合简单的一行逻辑，复杂逻辑用本地函数会更易维护。

关于Eric Lippert的说法 #

Eric Lippert提到“本地函数是带名称的Lambda”，这个描述在无捕获场景下是准确的——二者本质都是生成静态方法，只是本地函数有显式的名称，Lambda是匿名的。只有在捕获外部变量的场景下，本地函数的闭包处理才会比Lambda更高效（比如避免额外的类实例分配），但你的场景里没有捕获变量，所以这一点不适用。

总结 #

在你描述的这个简单场景下：

• 性能上没有可感知的差异，编译器对二者的委托缓存和方法生成逻辑基本一致。
• 本地函数在调试和可读性上更有优势，尤其是当你后续想要扩展键选择逻辑的时候。

内容的提问来源于stack exchange，提问作者Kasper van den Berg