CS9236: Compiling requires binding the lambda expression at least 100 times

[mu88]

Hi,

I'm now starting to see CS9236: Compiling requires binding the lambda expression at least 100 times for the following code:

private static int GetNumberOfProcessedRecordsByState(IReadOnlyCollection<BulkProcessingResult>[] bulkProcessingResults, ProcessState state) =>
    bulkProcessingResults.Sum(
        results => results
            .Where(result => result.ProcessState == state)
            .Sum(result => result.ProcessedRecords));

private static int GetNumberOfSavedRecordsByState(IReadOnlyCollection<BulkProcessingResult>[] bulkProcessingResults, ProcessState state) =>
    bulkProcessingResults.Sum(
        results => results
            .Where(result => result.ProcessState == state)
            .Sum(result => result.SavedRecords));

Unfortunately, I don't really find any documentation about this issue. I'd appreciate it if you guys could shed some light on it, and explain how it's triggered and how it can be resolved.

My understanding from the message would be that I should convert the code to something like this:

private static int GetNumberOfProcessedRecordsByState(IReadOnlyCollection<BulkProcessingResult>[] bulkProcessingResults, ProcessState state) =>
    bulkProcessingResults.Sum(
        (IReadOnlyCollection<BulkProcessingResult> results) => results
            .Where(result => result.ProcessState == state)
            .Sum((BulkProcessingResult result) => result.ProcessedRecords));

private static int GetNumberOfSavedRecordsByState(IReadOnlyCollection<BulkProcessingResult>[] bulkProcessingResults, ProcessState state) =>
    bulkProcessingResults.Sum(
        (IReadOnlyCollection<BulkProcessingResult> results) => results
            .Where(result => result.ProcessState == state)
            .Sum((BulkProcessingResult result) => result.SavedRecords));

However, as I don't find any docs or examples, I'd like to understand whether this is the intended fix and why it is necessary at all (some in-depth explanation would be very much appreciated).

Thank you :)

[huoyaoyuan]

The name of code 9236 is TooManyLambdas:

roslyn/src/Compilers/CSharp/Portable/Errors/ErrorCode.cs

Line 2311 in 75b26a2

INF_TooManyBoundLambdas = 9236,

And the triggering code is here:

roslyn/src/Compilers/CSharp/Portable/Binder/Binder_Lambda.cs

Lines 446 to 459 in 75b26a2

	foreach (var pair in bindings)
	{
	// The particular max value is arbitrary, but large enough so diagnostics should
	// only be reported for lambda expressions used as arguments to method calls
	// where the product of the number of applicable overloads for that method call
	// and for overloads for any containing lambda expressions is large.
	const int maxLambdaBinding = 100;
	int count = pair.Value;
	if (count > maxLambdaBinding)
	{
	int truncatedToHundreds = (count / 100) * 100;
	diagnostics.Add(ErrorCode.INF_TooManyBoundLambdas, GetAnonymousFunctionLocation(pair.Key), truncatedToHundreds);
	}
	}

Sample in unit test is here:

roslyn/src/Compilers/CSharp/Test/Semantic/Semantics/OverloadResolutionPerfTests.cs

Lines 291 to 346 in 75b26a2

	[ConditionalFact(typeof(IsRelease))]
	[WorkItem(40495, "https://github.com/dotnet/roslyn/issues/40495")]
	public void NestedLambdas_01()
	{
	var source =
	@"#nullable enable
	using System.Linq;
	class Program
	{
	static void Main()
	{
	Enumerable.Range(0, 1).Sum(a =>
	Enumerable.Range(0, 1).Sum(b =>
	Enumerable.Range(0, 1).Sum(c =>
	Enumerable.Range(0, 1).Sum(d =>
	Enumerable.Range(0, 1).Sum(e =>
	Enumerable.Range(0, 1).Sum(f =>
	Enumerable.Range(0, 1).Count(g => true)))))));
	}
	}";
	var comp = CreateCompilation(source);
	var diagnostics = comp.GetDiagnostics().Where(d => d is not { Severity: DiagnosticSeverity.Info, Code: (int)ErrorCode.INF_TooManyBoundLambdas });
	diagnostics.Verify();
	}
	/// <summary>
	/// A variation of <see cref="NestedLambdas_01"/> but with
	/// explicit parameter types and return type for the lambdas.
	/// </summary>
	[ConditionalFact(typeof(IsRelease))]
	public void NestedLambdas_WithParameterAndReturnTypes()
	{
	var source =
	@"#nullable enable
	using System.Linq;
	class Program
	{
	static void Main()
	{
	Enumerable.Range(0, 1).Sum(int (int a) =>
	Enumerable.Range(0, 1).Sum(int (int b) =>
	Enumerable.Range(0, 1).Sum(int (int c) =>
	Enumerable.Range(0, 1).Sum(int (int d) =>
	Enumerable.Range(0, 1).Sum(int (int e) =>
	Enumerable.Range(0, 1).Sum(int (int f) =>
	Enumerable.Range(0, 1).Sum(int (int g) =>
	Enumerable.Range(0, 1).Sum(int (int h) =>
	Enumerable.Range(0, 1).Sum(int (int i) =>
	Enumerable.Range(0, 1).Sum(int (int j) =>
	Enumerable.Range(0, 1).Sum(int (int k) =>
	Enumerable.Range(0, 1).Count(l => true))))))))))));
	}
	}";
	var comp = CreateCompilation(source);
	comp.VerifyDiagnostics();
	}

The samples are about deeply nested lambda causing overload resolution to take too much times.

[huoyaoyuan]

As the second unit test hints, adding more explicit type annotation for lambdas would reduce the work of overload resolution, and likely resolving the issue.

[ufcpp]

    bulkProcessingResults.Sum(
        results => results
            .Where(result => result.ProcessState == state)
            .Sum(int (result) => result.ProcessedRecords)); // Use explicit return type.

[mu88]

Thx - do you have any in-depth explanations/docs/blogs on why this is necessary?

[CyrusNajmabadi]

Overload resolution with lambdas has to try each possible conversion from each lambda to each target type. This then involves binding the bodies of the lambdas, which may involves doing the same in the interior, etc etc. This can trivially lead to a combinatorial explosion which can add up to seconds or minutes of compilation time.

By supplying the argument and return types, the compiler does not have to do this work, massively speeding things up in some pathological cases.

[rawling]

Has this got worse recently due to improvements (= more options) in overload resolutions for lambdas or something? I've never had an issue before but today have noticed VS (Intellisense) slowing down when I don't address these messages.
(Edit: only seems to dislike Sum, so something related to that?)

[CyrusNajmabadi]

It's possible you're compiling against a library that added more overloads. This would cause more binding.

(Edit: only seems to dislike Sum, so something related to that?)

It's likely there are more Sum overloads now.

[CyrusNajmabadi]

have noticed VS (Intellisense) slowing down when I don't address these messages.

Yes. This will slow down intellisense. We have to bind to understand what your code means. If binding needs to try hundreds of thousands of combinations, then that will slow down intellisense. Either break up the expression into smaller pieces, or provide typing hints.

[rawling]

It's likely there are more Sum overloads now.

I think maybe a combination of this, and that I've quite possibly never triple-nested Sum calls before (thanks, Advent of Code!)

or provide typing hints

Yeah - looks like I can fix it up by just specifying the return type on each of the lambdas that I pass into Sums. Useful new feature to have!

Thanks for following up.