Recently, I came across a Tweet claiming that using early returns in methods enhances performance. As usual, this post didn’t provide benchmark data, which always gets my attention. Whenever I see statements like this, I’m prompted to benchmark the claim, then share the findings on social media or as an article. This sparked the idea to start a new series called “dotNetDave’s Faster or Not!” modeled after Ripley’s Believe It or Not. Like Ripley’s tales that seem improbable yet are backed by real research, this series will explore performance claims in .NET and see if the data holds up.

Understanding Method Return Patterns

To kick off this series, let’s dive into code patterns for returning from methods. In the developer world, there are often debates on whether methods should return early or follow a more linear, single-exit flow. First, let’s examine a method without early returns. Though I don’t typically write methods like this, I asked ChatGPT to generate an example:

public bool IsValidUser(User user)
{
    bool isValid = true;

    if (user == null)
    {
        isValid = false;
    }
    else if (!user.IsActive)
    {
        isValid = false;
    }
    else if (!user.HasValidSubscription())
    {
        isValid = false;
    }

    return isValid;
}

This method checks for several conditions without returning immediately upon failure, leading to a single exit point. Some developers argue for this structure due to several perceived benefits:

• Single Exit Point: Can make the method more manageable and easier to debug.
• Consistent Flow for Complex Logic: Helps maintain readability in large, complex methods.
• Reduced Risk of Skipped Logic: With one exit point, every line of logic is executed.
• Simpler Debugging and Profiling: Single exit points can simplify breakpoints and stack tracing.
• Codebase Consistency: Teams prefer this style to keep code consistent across projects.

Early Returns

With an early return, however, the method exits as soon as a condition is met, avoiding further nesting. Here’s an example from my open-source project, Spargine, which uses early returns:

public new bool TryTake([NotNullWhen(true)] out T result)
{
    lock (this._lock)
    {
        if (base.TryTake(out result))
        {
            _ = this._hashCodes.Remove(result.GetHashCode());
            return true;
        }
        else
        {
            result = default;
            return false;
        }
    }
}

In this method, if TryTake() is successful, the hash code is removed from the collection, and the method returns immediately, avoiding additional code execution. This pattern offers several advantages:

• Improved Readability: By reducing nesting, early returns keep code clean and easy to follow.
• Simplified Complexity: Early returns allow edge cases and validations to be handled immediately.
• Performance Benefits: In some cases, early returns can enhance performance by avoiding unnecessary code execution.
• Adherence to SRP (Single Responsibility Principle): Early returns keep methods focused by handling irrelevant conditions early.
• Reduced State Tracking: Fewer variables need tracking, minimizing the chance of bugs.

Performance Testing

As a performance-focused developer (and author of a book on the subject), I like to make methods as fast as possible, especially in my open-source projects. I created two identical methods to test the performance difference, one using early return. Here’s the disassembly comparison of the two methods:

• DetermineRange(): Uses a single exit point with no early return.
• DetermineRangeEarlyReturn(): Exits early as soon as conditions allow.

Benchmark Results

The benchmarks for both methods showed the following times:

• DetermineRange(): 1.8236 ns
• DetermineRangeEarlyReturn(): 1.8040 ns

While the early-return method saved 0.0196 ns, the performance boost is minor. However, these small optimizations can add up over time in large applications, which is why I recommend early returns in many cases.

Conclusion

I hope you enjoyed this first entry in the “dotNetDave’s Faster or Not!” series. I plan to cover more performance myths and best practices, especially when I see claims about “better” code patterns that lack benchmark data. If you’re curious about the performance impact of a certain code pattern in .NET, feel free to reach out—I’m happy to benchmark it and publish the results.

Happy Coding!

Pick up any books by David McCarter by going to Amazon.com: http://bit.ly/RockYourCodeBooks

If you liked this article, please buy David a cup of Coffee by going here: https://www.buymeacoffee.com/dotnetdave

© The information in this article is copywritten and cannot be preproduced in any way without express permission from David McCarter.