使用 var 真的很慢吗?如果是这样,为什么?

发布于 2024-11-07 06:47:48 字数 182 浏览 1 评论 0原文

我正在学习 C# 和 .NET,并且经常在代码中使用关键字 var。我从 Eric Lippert 那里得到了这个想法,我喜欢它如何提高代码的可维护性。

不过,我想知道......博客中已经写了很多关于慢速堆定位引用的文章,但我自己并没有观察到这一点。这实际上很慢吗?我指的是由于类型推断导致的编译时间缓慢。

I am learning C# and .NET, and I frequently use the keyword var in my code. I got the idea from Eric Lippert and I like how it increases my code's maintainability.

I am wondering, though... much has been written in blogs about slow heap-located refs, yet I am not observing this myself. Is this actually slow? I am referring to slow compile times due to type inferencing.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

哽咽笑 2024-11-14 06:47:48

你说:

我指的是由于类型“推理”而导致编译时间缓慢

这不会减慢编译器的速度。编译器已经必须知道表达式的结果类型,以便检查赋值的兼容性(直接或间接)。在某些方面,使用这种已知类型删除了一些事情(例如,可能需要检查继承、接口和转换运算符)。

它也不会减慢运行时间;它们像常规 C# 变量一样完全静态编译(它们确实如此)。

简而言之...事实并非如此

You state:

I am referring to slow time for compile due to type 'inferencing'

This does not slow down the compiler. The compiler already has to know the result type of the expression, in order to check compatibility (direct or indirect) of the assignment. In some ways using this already-known type removes a few things (the potential to have to check for inheritance, interfaces and conversion operators, for example).

It also doesn't slow down the runtime; they are fully static compiled like regular c# variables (which they are).

In short... it doesn't.

待"谢繁草 2024-11-14 06:47:48

C# 中的“var”并不像您在 VB 中所习惯的那样是 VARIANT。 var 只是编译器允许您用来简写类型的语法糖。编译器计算出表达式右侧的类型并将变量设置为该类型。它根本没有性能影响 - 就像您键入完整的类型表达式一样:

var x = new X();

与这似乎是一个微不足道的示例完全相同

X x = new X();

,而且确实如此。当表达式更加复杂甚至“无法表达”(如匿名类型)和可枚举时,这确实很重要。

'var' in C# is not a VARIANT like you're used to in VB. var is simply syntactic sugar the compiler lets you use to shorthand the type. The compiler figures out the type of the right-hand side of the expression and sets your variable to that type. It has no performance impact at all - just the same as if you'd typed the full type expression:

var x = new X();

exactly the same as

X x = new X();

This seems like a trivial example, and it is. This really shines when the expression is much more complex or even 'unexpressable' (like anonymous types) and enumerables.

段念尘 2024-11-14 06:47:48

Var 在编译时被替换为您的实际变量类型。您在考虑动态吗?

Var is replaced at compile time with your actual variable type. Are you thinking of dynamic?

轮廓§ 2024-11-14 06:47:48

“变体”是无类型的,因此访问状态(或内部状态转换)始终必须经过两个步骤:(1)确定“真实”内部类型,以及(2)从该“真实”内部类型中提取相关状态。

当您从类型化对象开始时,您就没有这个两步过程。

确实,“变体”因此具有额外的开销。适当的使用是在您希望使用任何类型来简化代码的情况下,就像大多数脚本语言或非常高级的 API 所做的那样。在这些情况下,“变体”开销通常并不显着(因为无论如何您都在使用高级 API)。

但是,如果您正在谈论“var”,那么这只是您说“编译器,在此处放置正确的类型”的一种方便方式,因为您不想做这项工作,编译器应该能够弄清楚。在这种情况下,“var”并不代表(运行时)“变体”,而仅仅是源代码规范语法。

A "variant" is typeless, so access to state (or internal state conversion) always must go through two steps: (1) Determine the "real" internal type, and (2) Extract the relevant state from that "real" internal type.

You do not have that two-step process when you start with a typed object.

True, a "variant" thus has this additional overhead. The appropriate use is in those cases where you want the convenience of any-type for code simplicity, like is done with most scripting languages, or very high-level APIs. In those cases, the "variant" overhead is often not significant (since you are working at a high-level API anyway).

If you're talking about "var", though, then that is merely a convenience way for you to say, "Compiler, put the proper type here" because you don't want to do that work, and the compiler should be able to figure it out. In that case, "var" doesn't represent a (runtime) "variant", but rather a mere source-code specification syntax.

棒棒糖 2024-11-14 06:47:48

编译器从构造函数推断类型。

var myString = "123";string myString = "123"; 没有什么不同

,而且,一般来说,引用类型位于堆上,值类型位于堆栈上,无论它们是否使用 var 声明。

The compiler infers from the constructor the type.

var myString = "123"; is no different from string myString = "123";

Also, generally speaking, reference types live on the heap and value types live on the stack, regardless if they're declared using var.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文