perf: TimeoutHelper creates unnecessary allocations when no timeout is configured

[thomhurst]

Summary

TimeoutHelper.ExecuteWithTimeoutAsync creates unnecessary allocations even when no timeout is configured. This was identified via dotnet-trace profiling of the speed-comparison ScaleTests, where TimeoutHelper consumed 5.16% of CPU time for tests with no timeout.

Profiling Evidence

From dotnet-trace on ScaleTests (150 simple sync tests):

TimeoutHelper+<ExecuteWithTimeoutAsync>d__1.MoveNext()  5.16% inclusive

Root Cause

In TUnit.Engine/Helpers/TimeoutHelper.cs lines 59-78, the "fast path" when timeout is null still allocates when cancellationToken.CanBeCanceled is true:

if (!timeout.HasValue)
{
    var task = taskFactory(cancellationToken);

    if (!cancellationToken.CanBeCanceled)  // This is rarely true
    {
        return await task.ConfigureAwait(false);
    }

    // ALLOCATES: TaskCompletionSource + Task.WhenAny for every test!
    var tcs = new TaskCompletionSource<T>(TaskCreationOptions.RunContinuationsAsynchronously);
    using var reg = cancellationToken.Register(...);
    return await await Task.WhenAny(task, tcs.Task).ConfigureAwait(false);
}

Since cancellationToken.CanBeCanceled is typically true (tests run with cancellation support), every test creates:

• A TaskCompletionSource
• A cancellation registration
• A Task.WhenAny operation

Suggested Fix

When timeout is null, simply await the task directly. Cancellation is cooperative - the test code is already passed the token and should check it:

if (!timeout.HasValue)
{
    return await taskFactory(cancellationToken).ConfigureAwait(false);
}

The Task.WhenAny pattern is only needed when we want to return control immediately on timeout. Cancellation doesn't need this - we just need to propagate the exception when it occurs.

Impact

• Reduces per-test overhead by ~5% for tests without timeouts (majority of tests)
• Reduces allocations by removing TCS + registration + WhenAny per test
• Will improve TUnit's performance in DataDrivenTests and ScaleTests benchmarks where TUnit currently loses to other frameworks

[thomhurst]

Note on Cancellation Behavior

When removing the Task.WhenAny pattern for the no-timeout case, tests can still be cancelled when the engine cancellation token is cancelled. This is because:

1. The CancellationToken is passed directly to taskFactory(cancellationToken)
2. The test execution code receives this token via TestContext.CancellationToken
3. Source-generated test methods propagate the token to async operations
4. When cancellation is requested, the test's async operations will throw OperationCanceledException

The Task.WhenAny pattern was only needed for timeout scenarios where we want to return control immediately when the timeout elapses (before the test naturally completes). For cancellation, cooperative cancellation is sufficient - we just need the exception to propagate when the test checks the token or an awaited operation observes it.

This means the simplified code:

if (!timeout.HasValue)
{
    return await taskFactory(cancellationToken).ConfigureAwait(false);
}

Will still correctly handle:

• User-initiated cancellation (Ctrl+C)
• Engine shutdown
• Test session cancellation

The only difference is that cancellation won't interrupt a test that's blocked on a non-cancellable operation, but that's the expected behavior for cooperative cancellation.

[thomhurst]

Correction: Cancellation short-circuiting IS required

The previous comment was incorrect. We DO want to short-circuit tests when the engine cancellation token is cancelled, to prevent individual tests from hanging and keeping the test suite running longer than necessary.

The optimization opportunity is different: instead of manually creating TaskCompletionSource + CancellationToken.Register + Task.WhenAny, we can use the more efficient Task.WaitAsync(CancellationToken) API available in .NET 6+:

if (!timeout.HasValue)
{
    var task = taskFactory(cancellationToken);
    
#if NET6_0_OR_GREATER
    // More efficient - avoids TCS allocation
    return await task.WaitAsync(cancellationToken).ConfigureAwait(false);
#else
    if (!cancellationToken.CanBeCanceled)
    {
        return await task.ConfigureAwait(false);
    }
    
    // Fallback for older frameworks
    var tcs = new TaskCompletionSource<T>(TaskCreationOptions.RunContinuationsAsynchronously);
    using var reg = cancellationToken.Register(
        static state => ((TaskCompletionSource<T>)state!).TrySetCanceled(),
        tcs);
    return await await Task.WhenAny(task, tcs.Task).ConfigureAwait(false);
#endif
}

This maintains the short-circuit behavior on cancellation while reducing allocations on modern .NET versions.