Does adding return statements for C# methods improve performance?

Question

This blog says

12) Include Return Statements with in the Function/Method. How it improves performance Explicitly using return allows the JIT to perform slightly more optimizations. Without a return statement, each function/method is given several local variables on stack to transparently support returning values without the keyword. Keeping these around makes it harder for the JIT to optimize, and can impact the performance of your code. Look through your functions/methods and insert return as needed. It doesn't change the semantics of the code at all, and it can help you get more speed from your application.

I'm fairly sure that this is a false statement. But wanted to get the opinion experts out there. What do you guys think?

Answer 1

This statement does not apply to C#.

With C# you must explicitly set a "return" to have a valid function, without a return, you get a compile error to the effect of "not all code paths return a value".

With VB.NET this would apply as VB.NET does NOT have the requirement for an explicit return, and allows you to have functions that never return a value, as well as allow you to set the return using the name of the function.

To provide an example

In VB.NET you can do this

Function myFunction() As String
    myFunction = "MyValue"
End Function

Function myFunction2() As String
    'Your code here
End Function

The above compiles, neither with an explicit "returns", there is more overhead involved in this.

If you try to do this with C#

string myFunction()
{
    //Error due to "Cannot assign to 'myFunction' because it is a 'Method Group'
    myFunction = "test";
}

string myFunction2()
{
    //Error due to "not all code paths return a value
}

My comments note the errors that you get.

Answer 2

My only guess here is that he's talking about VB.NET not C#. VB.NET allows you to somethin like this to return values

Public Function GetSomething() As Int
     GetSomething = 4
End Function

My VB is incredibly out of date though. This may be slower that using an explicit return statement

Answer 3

The post is kind of vague. Being a C# developer, my first thought was "as opposed to what?". However, he could be referring to something like:

public bool MyFunction()
{
    bool result = false;
    if (someCondition == true)
    {
        // Do some processing
        result = true;
    }
    else if (someOtherCondition == true)
    {
       // Do some processing
       result = true;
    }
    // ... keep going

    return result;
}

He may be suggesting that replacing the result = true; statements with return true; may perform better. I'm not sure about that personally... that's pretty deep into JIT theory at that point, and I think any gains that are made would be very minor compared to other performance improvements that you could make.

Answer 4

Generally there are 2 spots in which I exit a function. At the very beginning of my methods to validate incoming data:

if (myParameter == null)
   throw new ArgumentNullException("myParameter");

And/or at the very end of the method.

private bool GetSomeValue()
{
    bool returnValue = false;
    // some code here
    if (some condition)
    {
        returnValue = some expression
    }
    else
    {
        returnValue = some other expression;
    }
    return returnValue;
}

The reason I don't return inside of the conditional, is so that there is 1 exit point of the function, it helps with debugging. No one wants to have to maintain a method with 12 return statements in it. But that is just a personal opinion of mine. I would err on the side of readability, and not worry about optimization unless you're dealing with a real-time must-go-faster situation.

Answer 5

It is somewhat true, both for VB.NET and C#. In C# the programmer has to declare the variable that holds the return value explicitly, it is automatic in VB.NET. Most return values are returned in the EAX or RAX register, the JIT compiler has to generate code to load the register from the return value variable before the function exits. When you use the return statement, the JIT compiler might have the opportunity to load the EAX register directly, or already have the register containing the correct value, and jump to the function exit code, bypassing the load-from-variable instruction.

That's a pretty big "might" btw, real code invariably tests some expression with the if() statement. Evaluating that expression almost always involves using the EAX register, it still has to be reloaded with the return value. The x64 JIT compiler does a completely different job doing that compared to the x86 compiler, the latter always seems to use the variable in a few spot checks I did. So you're not likely to be ahead unless you run on a 64-bit version of Windows.

Of all the evil in premature optimization, this one is arguably the worst. The potential time savings are minuscule, write your code for clarity first. Profile later.

Answer 6

I'd disagree - I think a single in and single out of every method makes code much easier to read and debug. Multiple return statements in a function can make navigating code more comlpex. In fact (if possible to refactor) its better to have more smaller functions than say larger functions with multiple exits.