首先，要真正回答的性能问题的唯一方法是实际尝试这两种方法在现实条件下测试的结果。

First off, the only way to actually answer performance questions is to actually try it both ways and test the results in realistic conditions.

不过，这不能不说的编译不这样做优化，因为该属性可能有副作用，其他的答案是正确和错误。这样的问题（除了那根本不能没有真正尝试它，测量结果回答的根本问题）的问题是，编译实际上是两个编译器：C＃编译器，其编译成MSIL，而JIT编译器，其编译的IL机器code。

That said, the other answers which say that "the compiler" does not do this optimization because the property might have side effects are both right and wrong. The problem with the question (aside from the fundamental problem that it simply cannot be answered without actually trying it and measuring the result) is that "the compiler" is actually two compilers: the C# compiler, which compiles to MSIL, and the JIT compiler, which compiles IL to machine code.

C＃编译器永远不会做这种优化;如前所述，这样做需要编译器对进入code被称为并验证其计算结果不超过被叫方的code的寿命变化。 C＃编译器不会这么做。

The C# compiler never ever does this sort of optimization; as noted, doing so would require that the compiler peer into the code being called and verify that the result it computes does not change over the lifetime of the callee's code. The C# compiler does not do so.

JIT编译器的威力。没有理由不能。它具有所有code坐在那里。它是完全免费的内联属性getter，如果抖动确定内联属性getter返回可以缓存在登记册，并重新使用的值，那么它是完全可以这样做。 （如果你不想这样做，因为该值可以修改在另一个线程，那么你已经有一个竞争条件的错误;修复bug，你不用担心演出前）

The JIT compiler might. No reason why it couldn't. It has all the code sitting right there. It is completely free to inline the property getter, and if the jitter determines that the inlined property getter returns a value that can be cached in a register and re-used, then it is free to do so. (If you don't want it to do so because the value could be modified on another thread then you already have a race condition bug; fix the bug before you worry about performance.)

无论是实际的确实的内联属性提取，然后enregister的价值，我也没办法。我知道几乎一无所知抖动。但它允许这样做，如果它认为合适的。如果你是好奇它是否这样做或没有，你可以（1）问别人谁是上写的抖动，或（2）检查即时编译code在调试器的团队。

Whether the jitter actually does inline the property fetch and then enregister the value, I have no idea. I know practically nothing about the jitter. But it is allowed to do so if it sees fit. If you are curious about whether it does so or not, you can either (1) ask someone who is on the team that wrote the jitter, or (2) examine the jitted code in the debugger.

最后，请允许我借此机会指出，计算结果一次，并将结果存储并重新使用它的并不总是一个优化的。这是一个令人惊讶的复杂的问题。有各种各样的事情来优化：

And finally, let me take this opportunity to note that computing results once, storing the result and re-using it is not always an optimization. This is a surprisingly complicated question. There are all kinds of things to optimize for:

• 执行时间

• execution time

执行code尺寸 - 这对执行时间产生重大影响，因为大code需要更长的时间来加载，提高了工作集大小，把pressure在处理器缓存，内存和页面文件。小慢code是经常从长远来看的更快的比大快code像的启动时间和缓存位置重要的指标。

executable code size -- this has a major effect on executable time because big code takes longer to load, increases the working set size, puts pressure on processor caches, RAM and the page file. Small slow code is often in the long run faster than big fast code in important metrics like startup time and cache locality.

寄存器分配 - 这也是对执行时间产生重大影响，特别是在像x86体系结构具有少量可用的寄存器。 Enregistering快速重新使用的值可以表示存在可用于需要优化其他操作更少的寄存器;也许是优化这些操作，而不是将是一个净赢。

register allocation -- this also has a major effect on execution time, particularly in architectures like x86 which have a small number of available registers. Enregistering a value for fast re-use can mean that there are fewer registers available for other operations that need optimization; perhaps optimizing those operations instead would be a net win.

等。它得到真正复杂的真正快速。

and so on. It get real complicated real fast.

总之，你不可能知道是否写入code缓存的结果，而不是重新计算它实际上是（1）速度更快，或（2）性能更好。 更好的性能并不总是意味着制作执行的特定程序更快的更好的性能大约是搞清楚什么资源是重要的用户 - 执行时间，记忆，工作集，启动时间，等等 - 优化了这些事情。你不能这样做，没有（1）谈论你的客户，了解他们所关心的，和（2）实际测量，看看你的变化是具有在所需方向可测量的效果。

In short, you cannot possibly know whether writing the code to cache the result rather than recomputing it is actually (1) faster, or (2) better performing. Better performance does not always mean making execution of a particular routine faster. Better performance is about figuring out what resources are important to the user -- execution time, memory, working set, startup time, and so on -- and optimizing for those things. You cannot do that without (1) talking to your customers to find out what they care about, and (2) actually measuring to see if your changes are having a measurable effect in the desired direction.