Debug Console reports "Evaluation timed out" when lambda expressions are used with large collections

[LanceUMatthews]

Issue Description

I am trying to use the debugger to inspect large collections (thousands of elements). Rather than continually clicking "More" in the Variables or Watch panes to expand 25 elements at a time, I thought I could use LINQ call chains in Debug Console to slice and dice the data down to the desired set, but I'm finding that the expressions keep timing out if I pass a lambda expression (e.g. Where(i => i % 2 == 0). If I instead pass a method/delegate that is already part of the compiled code (e.g. Where(isEven)) then it works (usually - see below), but that requires stopping the debugger to add one-off debug delegates to my application.

Steps to Reproduce

Create and start debugging a console application with the following code:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;

static class Program
{
    const int RangeSize = 100_000;
    static IEnumerable<int> Range { get; } = Enumerable.Range(0, RangeSize);

    static void CountRange(Func<int, bool>? predicate = null)
    {
        Stopwatch watch = Stopwatch.StartNew();
        int count = predicate == null ? Range.Count() : Range.Count(predicate);

        Console.WriteLine($"count is {count:N0} (took {watch.Elapsed.TotalMilliseconds:N1}ms)");
    }

    static Func<int, bool> IsEven_Lambda { get; } = i => i % 2 == 0;

    static bool IsEven_Method(int i)
    {
        return i % 2 == 0;
    }

    static Func<int, bool> IsEven_MethodGroup { get; } = IsEven_Method;

    static void Main()
    {
        Func<int, bool> isEven = i => i % 2 == 0;
        Func<int, bool> isMagic = i => i == 12345;

        Console.WriteLine("Counting all elements...");
        CountRange();

        Console.WriteLine("Counting even elements...");
        CountRange(i => i % 2 == 0);
        CountRange(isEven);
        CountRange(IsEven_Lambda);
        CountRange(IsEven_Method);
        CountRange(IsEven_MethodGroup);

        Console.WriteLine("Counting magic elements...");
        CountRange(i => i == 12345);
        CountRange(isMagic);

        Debugger.Break();
        // Now evaluate the same predicates as above in Debug Console...
        //     Range.Count()
        //     Range.Count(i => i % 2 == 0)
        //     Range.Count(isEven)
        //     Range.Count(IsEven_Lambda)
        //     Range.Count(IsEven_Method)
        //     Range.Count(IsEven_MethodGroup)
        //     Range.Count(i => i == 12345)
        //     Range.Count(isMagic)
        // ...and try creating large arrays to inspect
        //     Range.ToArray()
        //     Range.Where(i => i % 2 == 0).ToArray()
        //     Range.Where(isEven).ToArray()
    }
}

It may be necessary to increase the value of RangeSize to reproduce this issue on hardware faster than mine.

Expected Behavior

Method calls that are passed lambda expressions and execute very quickly in application code should not cause timeouts in Debug Console.

Actual Behavior

When the debugger breaks the console output to that point shows that the various forms of expressing the same predicate are all taking on the order of milliseconds to execute and producing the correct results:

Counting all elements...
count is 100,000 (took 15.2ms)
Counting even elements...
count is 50,000 (took 4.9ms)
count is 50,000 (took 1.8ms)
count is 50,000 (took 1.6ms)
count is 50,000 (took 1.8ms)
count is 50,000 (took 1.7ms)
Counting magic elements...
count is 1 (took 1.0ms)
count is 1 (took 1.0ms)

When those same predicates are used in Debug Console, however, evaluation times out after several seconds in the cases where a lambda expression is used:

→Range.Count()
 100000
→Range.Count(i => i % 2 == 0)
 Evaluation timed out
→Range.Count(isEven)
 50000
→Range.Count(IsEven_Lambda)
 50000
→Range.Count(IsEven_Method)
 Evaluation timed out
→Range.Count(IsEven_MethodGroup)
 50000
→Range.Count(i => i == 12345)
 Evaluation timed out
→Range.Count(isMagic)
 1
→Range.ToArray()
 {int[100000]}
→Range.Where(i => i % 2 == 0).ToArray()
 Evaluation timed out
→Range.Where(isEven).ToArray()
 {int[50000]}

I included the three IsEven_* test cases because in creating this example code I found that, unexpectedly, Range.Count(IsEven_Method) also times out when evaluated by Debug Console.

The problematic expressions continue to timeout on subsequent attempts:

→Range.Count(i => i % 2 == 0)
 Evaluation timed out
→Range.Count(i => i % 2 == 0)
 Evaluation timed out
→Range.Count(IsEven_Method)
 Evaluation timed out
→Range.Count(IsEven_Method)
 Evaluation timed out
→Range.Count(i => i == 12345)
 Evaluation timed out
→Range.Count(i => i == 12345)
 Evaluation timed out
→Range.Where(i => i % 2 == 0).ToArray()
 Evaluation timed out
→Range.Where(i => i % 2 == 0).ToArray()
 Evaluation timed out

If I decrease RangeSize to, say, 50_000 then the expressions returning a scalar value...

• Range.Count(i => i % 2 == 0)
• Range.Count(IsEven_Method)
• Range.Count(i => i == 12345)

...are able to complete (albeit still taking several seconds each to do so), but Range.Where(i => i % 2 == 0).ToArray() continues to times out.

Environment information

Windows 10

VSCode version: 1.97.2
C# Extension: 2.63.32
Using OmniSharp: false

Dotnet Information

.NET SDK: Version: 9.0.200 Commit: 90e8b202f2 Workload version: 9.0.200-manifests.c4f6226a MSBuild version: 17.13.8+cbc39bea8

Runtime Environment:
OS Name: Windows
OS Version: 10.0.19045
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.200\

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
Version: 9.0.2
Architecture: x64
Commit: 80aa709f5d

.NET SDKs installed:
8.0.309 [C:\Program Files\dotnet\sdk]
9.0.200 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 8.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

Visual Studio Code Extensions

Extension	Author	Version	Folder Name
azure-repos	ms-vscode	0.40.0	ms-vscode.azure-repos-0.40.0
csdevkit	ms-dotnettools	1.16.6	ms-dotnettools.csdevkit-1.16.6-win32-x64
csharp	ms-dotnettools	2.63.32	ms-dotnettools.csharp-2.63.32-win32-x64
githistory	donjayamanne	0.6.20	donjayamanne.githistory-0.6.20
hexeditor	ms-vscode	1.11.1	ms-vscode.hexeditor-1.11.1
powershell	ms-vscode	2025.0.0	ms-vscode.powershell-2025.0.0
remote-repositories	ms-vscode	0.42.0	ms-vscode.remote-repositories-0.42.0
remotehub	GitHub	0.64.0	github.remotehub-0.64.0
svg	jock	1.5.4	jock.svg-1.5.4
vscode-dotnet-runtime	ms-dotnettools	2.2.8	ms-dotnettools.vscode-dotnet-runtime-2.2.8
xml	DotJoshJohnson	2.5.1	dotjoshjohnson.xml-2.5.1

Debian 12

VSCode version: 1.97.2
C# Extension: 2.63.32
Using OmniSharp: false

Dotnet Information

.NET SDK: Version: 9.0.200 Commit: 90e8b202f2 Workload version: 9.0.200-manifests.b4a8049f MSBuild version: 17.13.8+cbc39bea8

Runtime Environment:
OS Name: debian
OS Version: 12
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/9.0.200/

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
Version: 9.0.2
Architecture: x64
Commit: 80aa709f5d

.NET SDKs installed:
9.0.200 [/usr/share/dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 9.0.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 9.0.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
None

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

Visual Studio Code Extensions

Extension	Author	Version	Folder Name
csdevkit	ms-dotnettools	1.16.6	ms-dotnettools.csdevkit-1.16.6-linux-x64
csharp	ms-dotnettools	2.63.32	ms-dotnettools.csharp-2.63.32-linux-x64
vscode-dotnet-runtime	ms-dotnettools	2.2.8	ms-dotnettools.vscode-dotnet-runtime-2.2.8

[gregg-miskelly]

Hi @LanceUMatthews, because of the way Lamba evaluation needs to work, there is no way to make evaluating a Lamba fast. But:

1. At the time evaluation was implemented, VS Code had no way to support cancellation, but that is no longer the case. So, we should probably switch to using cancellation instead so if you have a large collection that you need to evaluate it is possible.
2. There hasn't been any performance tuning of this area in a long time, and while it will always be multiple orders of magnitude slower than non-lambda evaluation, I would also not be surprised if there aren't some huge wins here.

In case you are interested, the reason Lambda evaluation is so much slower is that for non-Lambda evaluation, generally the debugger can directly execute that function in the target process, which is called 'func eval'. This isn't possible with Lambda evaluation as there aren't great ways to directly create that Lambda in the target process. So instead, the debugger will interpret all the code needed to run the expression. This is much slower since (1) all the state needs to be pulled from the target process -and- (2) instead of running on the super-optimized .NET runtime, it is running on a simple interpreter.

[LanceUMatthews]

Thanks, @gregg-miskelly, for that explanation. I thought Code must certainly be dynamically compiling the lambdas and, thus, they'd execute at full speed, but now I see that is not the case. Of course only after posting this did I think to compare with how the Visual Studio 2022 debugger performs and found that, too, would timeout under the same conditions.

I wonder if perhaps the "Evaluation timed out" message could indicate when the debugger had to use interpretation so the user can distinguish between evaluation timing out (possibly) because the expression does not run at the speed of compiled code vs. the expression would take a long time to run even without the debugger.

Do you have any thoughts on why passing IsEven_Method times out but IsEven_MethodGroup does not? I would expect those two to perform the same. Is it much the same thing that IsEven_MethodGroup is a delegate that has already been created whereas with IsEven_Method the debugger has to do so itself (and the interpreter is somehow involved)?

[gregg-miskelly]

I wonder if perhaps the "Evaluation timed out" message could indicate when the debugger had to use interpretation so the user can distinguish between evaluation timing out (possibly) because the expression does not run at the speed of compiled code vs. the expression would take a long time to run even without the debugger.

I think that makes sense to me. The one tricky bit would be that, as you are discovering yourself (see method group comment), exactly when the debugger needs to interpret vs use function evaluation is complicated. But I bet we could come up with an error message which gave a little hint without being too confusing.

Do you have any thoughts on why passing IsEven_Method times out but IsEven_MethodGroup does not?

This is because, in the MethodGroup case a delegate object exists, so the debugger can reuse it. In the IsEven_Method case the debugger would need to create a delegate, and it doesn't know how to do that. I would need to do more research to see if the debugger could optimize the case of creating a delegate to a function that already exists in the target process, or if the .NET Debugging services don't have a way of doing that at all.

[gregg-miskelly]

FYI The next version of the debugger that we insert will partially fix this issue:

1. More to come, but we made the interpreter ~20% faster
2. We no longer will use timeouts in evaluations from the Debug Console. Instead, a progress UI will pop up for evaluations that take more than 500ms, and that will allow cancellation (see demo).