在 .Net 中创建局部变量
我只是想知道创建局部变量来接受函数的返回值会影响 .Net 应用程序中的内存使用或性能，尤其是在 ASP.Net 中。
说
MyObject myObject = Foo();
MyOtherObject myOtherObject = Boo();
SomeFuntion(myObject, myOtherObject);
OR
我应该使用
MyFunction(Foo(), Boo());
当然前一种用法具有更好的可读性..但是内存使用和性能怎么样？
提前致谢 123开发商
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不要过早优化； 在发布版本中，编译器很可能无论如何都会优化这些！ 无论哪种方式，您只是谈论（大概）一些引用的少量堆栈空间。 两种方法都可以； 选择更具可读性的那个。
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.
CIL（C# 编译成的中间语言）是一种基于堆栈的语言，因此中间函数的返回值无论如何都需要先存放在堆栈上，然后才能作为参数传递给最终函数。
无法根据局部变量来预测 C# 编译器将执行的操作[1]； 当您这样做时，它可能会决定使用局部变量，或者它可能会使用堆栈行为并完全跳过它们。 同样，即使您不使用局部变量，它也可能会合成局部变量，也可能不会。
无论哪种方式，性能差异都不值得担心。
[1] 是的，当然，您可以编译并查看它生成的 IL 以确定它将做什么，但这仅对您正在使用的编译器的当前版本有效，并且您不应该依赖的实现细节。
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.
我相信内存性能基本上是相同的。 除非性能测试显示出显着差异，否则请选择具有增强可读性的选项。
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.
不要害怕使用局部变量。 内存使用和性能的差异非常小，或者在某些情况下根本没有差异。
在您的特定情况下，局部变量可能使用 8 个字节（在 64 位应用程序上为 16 个字节）的堆栈空间。 但是，如果需要临时存储，编译器可以自行创建局部变量，因此两个版本都可能具有相同的局部变量集。
此外，编译器可以使用处理器寄存器而不是堆栈空间来存储某些局部变量，因此甚至不能确定创建局部变量实际上是否使用任何堆栈空间。
无论如何，分配堆栈空间非常便宜。 当调用该方法时，会为该方法中的本地数据创建一个堆栈帧。 如果必须分配更多内存，那只会改变堆栈指针的移动量，而根本不会产生任何额外的代码。
因此，只需编写可维护且健壮的代码，并相信编译器会优化变量的使用。
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.