如今优化似乎是一种迷失的艺术.所有程序员都没有从代码中挤出每一盎司的效率吗？经常在雪地里行走五英里的时候这样做？
本着回归丢失的艺术的精神,您知道的简单(或复杂)变化以优化C#/ .NET代码的一些提示是什么？因为它是如此广泛,取决于一个人想要完成什么,它有助于提供你的提示的背景.例如:
StringBuilder.请参阅底部的链接以了解相关信息.string.Compare两个字符串比较,而不是做这样的事情string1.ToLower() == string2.ToLower()到目前为止,普遍的共识似乎是衡量关键.这种方式忽略了这一点:测量不会告诉你什么是错的,或者如果遇到瓶颈会怎么做.我遇到了字符串连接瓶颈一次,不知道该怎么办,所以这些提示很有用.
我甚至发布这个问题的意思是为了解决常见的瓶颈问题,以及在遇到这些问题之前如何避免它们.它甚至不一定是任何人应该盲目遵循的即插即用代码,而是更多关于获得对性能应该被考虑的理解,至少在某种程度上,并且需要注意一些常见的陷阱.
我可以看到,知道为什么提示有用以及应该应用的位置可能会有用.对于StringBuilder小费,我找到了很久以前在Jon Skeet网站上做过的帮助.
在观看Joshua Bloch的演出"表现焦虑"后,我阅读了他在"评估Java Pro fi lers的准确性"演讲中提出的论文.引用结论:
我们的结果是令人不安的,因为它们表明在我们的七个基准测试和两个生产JVM中大多数普遍存在的错误 - 并且显着 - 所有四个最先进的专业人员都会产生不正确的专业知识.不正确的配置文件很容易导致性能分析师花时间优化对性能影响最小的冷方法.我们表明,不使用屈服点进行采样的概念验证问题不会遇到上述问题
论文的结论是我们无法真正相信剖析器的结果.但是,使用分析器的替代方法是什么.我们应该回去,只是用我们的感觉做优化吗？
更新:讨论中似乎遗漏的一点是观察者效应.我们能否建立一个真正" 观察者效应 " 的探测器- 免费？
我看到这个术语使用了很多,但我觉得大多数人都是出于懒惰或无知而使用它.例如,我正在阅读这篇文章:
http://blogs.msdn.com/b/ricom/archive/2006/09/07/745085.aspx
他谈到他的决定,他为实现他的应用程序所需的类型.
如果是我,谈论这些我们需要编写的代码,其他程序员会想到:
或两者.
并建议只是实施它,而不是担心这些,直到它们成为一个问题.
哪个更优惠？
在完成任何实施之前,如何区分性能关键应用程序的过早优化与知情决策？