CS9236: Compiling requires binding the lambda expression at least 100 times #74799
-
|
Hi, I'm now starting to see 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 :) |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 16 replies
-
|
The name of code 9236 is TooManyLambdas: And the triggering code is here: roslyn/src/Compilers/CSharp/Portable/Binder/Binder_Lambda.cs Lines 446 to 459 in 75b26a2 Sample in unit test is here: The samples are about deeply nested lambda causing overload resolution to take too much times. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
bulkProcessingResults.Sum(
results => results
.Where(result => result.ProcessState == state)
.Sum(int (result) => result.ProcessedRecords)); // Use explicit return type. |
Beta Was this translation helpful? Give feedback.
-
|
Thx - do you have any in-depth explanations/docs/blogs on why this is necessary? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
It's possible you're compiling against a library that added more overloads. This would cause more binding.
It's likely there are more Sum overloads now. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
I think maybe a combination of this, and that I've quite possibly never triple-nested
Yeah - looks like I can fix it up by just specifying the return type on each of the lambdas that I pass into Thanks for following up. |
Beta Was this translation helpful? Give feedback.
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.