Performance Problems with Lambdas

In LINQ Cookbook, Recipe 5: Concatenating the selected strings from a CheckedListBox, Microsoft's Visual Basic team demonstrates two ways to build string concatenators using features in VB 9.

In their first version, they show how to use LINQ's Aggregate syntax. The code that generates the comma separated list looks like this:

MsgBox( _
	Aggregate Box In CheckedListBox1.CheckedItems _ 
	Into Concat()) 

Concat itself is a an extension method implemented as such:

Public Module AggregateModule 
	Public Function Concat(Of Type)( _ 
		ByVal ie As IEnumerable(Of Type)) As String 
		Dim str As String = "" 
		For Each item In ie 
			If str <> "" Then str &= "," 
			str &= item.ToString() 
		Next 
		Return str 
	End Function 
End Module 

Rather than going through the trouble of creating an extension method, both C# and VB developers also have the option of using Lambdas. The syntax is a little more complex, but not by much.

MsgBox((From c In _ 
	CheckedListBox1.CheckedItems).Aggregate( _ 
	Function(ByVal x, ByVal y) x + "," + y)) 

Bill McCarthy points out that this second syntax has some issues, including performance.

The extension method approach could be improved by using a string builder, but how do you use a String builder when using the lambda approach? If you can't then at the end of the day, the lambda ends up creating multiple strings for each concat, and in .NET that's one of the no-no's for writing string concatenation. The extension method though you can refactor and tune to use a StringBuilder.

Another issue Bill McCarthy brings up is that lambdas are not factored for reuse. Lambdas usually exist in the context of a single function, so unless they are returned as a delegate there is no way to share them. This is not as much as an issue for VB, which only has single-line lambdas in this release, but will be a concern for those using the longer lambdas possible in C#.