views:

231

answers:

4

Hey all,

I just want to know that creating local variables to accept the return value of function is going to hit memory usage or performance in .Net applications , especially in ASP.Net.

say

 MyObject myObject = Foo();
 MyOtherObject myOtherObject = Boo();

 SomeFuntion(myObject, myOtherObject);

OR

Should I use

 MyFunction(Foo(), Boo());

Certainly the former usage has a better readability.. But what about the memory usage and performance?

Thanks in advance 123Developer

+14  A: 

Don't optimise prematurely; in a release build it is quite likely that the compiler will optimise these away anyway! Either way, you are just talking a tiny amount of stack space for (presumably) a few references. Either approach is fine; go with whichever is more readable.

Marc Gravell
Concur. Besides, you'd have to have quite severe loads on a function like this in order to have measurable impact on performance. In an ASP.NET application, focus first on what you're doing with viewstate and anything else sent over the network.
Pontus Gagge
I, for one, welcome our new compiler overlords.
Will
+2  A: 

I believe the memory performance would be essentially the same. And unless performance testing were to show a significant difference, choose the option with enhanced readability.

Timothy Carter
+5  A: 

CIL (the intermediate language into which C# is compiled) is a stack-based language so the return values of the intermediate functions need to end up on the stack before being passed as arguments to the final one anyway.

There's no way of predicting what the C# compiler will do[1] in terms of locals; it may decide to use locals when you do, or it may use the stack behaviour and skip them altogether. Similarly it may synthesize locals even when you don't use them, or it might not.

Either way, the performance difference isn't worth worrying about.


[1] Yes, of course, you can compile and look at the IL it produces to determine what it will do, but that is only valid for the current version of the compiler you're using and is an implementation detail you shouldn't rely on.

Greg Beech
+1 for mentioning the stack creation in any case. Perfect answer IMO.
Reed Copsey
A: 

Don't be afraid to use local variables. The difference in memory usage and performance is very small, or in some cases none at all.

In your specific case the local variables may use 8 bytes (16 bytes on a 64-bit application) of stack space. However, the compiler can create local variables by itself if it's needed for temporary storage, so it's possible that both versions have the same set of local variables anyway.

Also, the compiler can use processor registers instead of stack space for some local variables, so it's not even certain that creating a local variable actually uses any stack space at all.

Allocating stack space is very cheap anyhow. When the method is called, a stack frame is created for the local data in the method. If more memory has to be allocated, that will only change how much the stack pointer is moved, it will not produce any extra code at all.

So, just write the code so that it's maintainable and robust, and trust the compiler to optimize the variable usage.

Guffa