26

我们更多的C#代码发布是建立与“优化代码”选项关闭。我相信这是为了允许在发布模式下构建的代码更容易调试。优势打造

鉴于我们正在创造它连接到后端的Web服务相当简单的桌面软件,(即不是特别处理器密集型应用程序),那么如果任何类型的性能损失可能期望什么呢?

并且任何特定的平台可能会受到更严重的影响?例如。多处理器/ 64位。

+0

我已经看到了这个谬论运行在旧的商店仍旧陷于C/C++文化中,因为他们(宣称)试图转向更新的技术。 –

+0

@Greg D - 有趣的是,我原以为C++文化会更喜欢优化 - 或者这不是您的意思? –

+1

@gt:我最常遇到的C++文化_claims_喜欢优化和“快速代码”,但大多数这样的说法都是基于对任何新事物或不同事物的迷信和无理的恐惧。我不否认我所指的文化功能障碍,但我确实认为它在这个特定的商店之外也很普遍。尽管有相反的证据,尽管有相反的证据,但他们坚持认为_their_ C++代码具有比一些合理编写的C#代码更优异的性能特征,例如令人惊讶的人数。我经常听到“我会管理自己的记忆,谢谢你”。 –

回答

13

完整的详细信息,请http://blogs.msdn.com/jaybaz_ms/archive/2004/06/28/168314.aspx

简单...

在托管代码,在运行时的抖动程度几乎所有的优化。从这个标志产生的IL的差异非常小。

+5

我不确定为什么那个报价很重要。即使生成的IL不是,JITter的优化也会受到该标志的影响,因此该标志将对性能产生影响。原来的问题是关于这种差异的大小。 – phoog

2

由编译器完成的优化是相当低的水平,不会影响用户的体验。

如果您想以量化对应用程序的优化,只需轮廓非优化和优化构建,并比较结果。

+0

我注意到调试器在它存在时跳过行。这在VS 2013和15顺便!有时我只是为了调试目的而在本地切断它。 – arviman

6

其实是有区别的,有时相当显著。什么能真正影响性能(因为它是一些JIT没有充分照顾):

  • 不必要的局部变量(即,更大的堆栈每个呼叫帧)
  • 过于笼统条件指令,JIT翻译他们以相当直接的方式。
  • 不必要的分支(也不能由JIT服务好 - 毕竟,它没有太多的时间来完成所有的智能优化技术)

    所以,如果你正在做一些数字 - 打开优化。否则,你根本看不到任何区别。

26

您是唯一可以回答“性能问题”问题的人。尝试两种方式,衡量性能,看看会发生什么。命中可能是巨大的,或者可能是不灵敏的;没有人阅读这篇文章,知道对您来说“巨大”意味着一微秒还是二十分钟。

如果你有兴趣在由C#编译器都做了什么优化 - 而不是抖动 - 在优化开关接通时,看到:

http://blogs.msdn.com/ericlippert/archive/2009/06/11/what-does-the-optimize-switch-do.aspx