优化C#/.NET程序的技巧

Question

优化C#/.NET程序的技巧现在看来，优化是一门丢失的艺术。难道不是有一段时间，所有的程序员都在压缩他们的代码的每一盎司的效率吗？在雪中行走五英里时经常这样做？本着找回失去的艺术的精神，对于简单的(或者可能是复杂的)更改来优化C#/.NET代码，您知道哪些技巧？因为这是一件非常广泛的事情，这取决于一个人想要完成什么，这将有助于为你的技巧提供背景。例如：将多个字符串连接在一起时，请使用StringBuilder相反。请参阅底部的链接，以了解对此的注意事项。使用string.Compare比较两个字符串而不是执行类似的操作string1.ToLower() == string2.ToLower()到目前为止，普遍的共识似乎是衡量的关键。这种情况忽略了要点：测量并不能告诉你哪里出了问题，或者如果你遇到瓶颈该怎么办。我曾经遇到过字符串连接瓶颈，不知道该怎么办，所以这些技巧是有用的。我甚至发布这篇文章的目的是要为常见的瓶颈提供一个位置，以及在遇到这些瓶颈之前如何避免这些瓶颈。任何人都不一定要盲目地遵循即插即用代码，而是要更多地理解，至少在某种程度上，应该考虑性能，还有一些常见的缺陷需要注意。不过，我可以看出，知道小费为什么有用，以及应该在哪里应用，也可能是有用的。为StringBuilder提示我找到了我很久以前做过的帮助在乔恩·斯基特的网站上.

Answer 1

现在看来，优化是一门丢失的艺术。

曾经有一天，显微镜的制造被当作一门艺术来实践。人们对光学原理知之甚少。零件没有标准化。管子、齿轮和镜片必须由高技能的工人手工制作。

如今，显微镜是作为一门工程学科而产生的。物理的基本原理是非常清楚的，现成的零件是广泛可用的，显微镜制造工程师可以作出明智的选择，如何优化他们的仪器来完成它设计的任务。

表现分析是一种“失传的艺术”，是一件非常好的事情。那门艺术是被实践的作为一种艺术..应该根据实际情况进行优化：工程问题可通过仔细应用固体工程原理来解决。

多年来，我多次被问及我的“技巧和技巧”清单，人们可以用这些方法来优化VBScript/jscript/他们的活动服务器页面/他们的VB/他们的C#代码。我总是抗拒这个。强调“技巧和技巧”是完全错误的方式来接近性能。这种方式导致的代码很难理解，很难推理，很难维护，这通常不会比相应的直接代码更快。

处理性能的正确方法是将其作为一个工程问题来处理，就像任何其他问题一样：

• 设定有意义的、可衡量的、以客户为中心的目标.
• 构建测试套件，在现实但可控制和可重复的条件下对照这些目标测试您的性能。
• 如果这些套件显示你没有达到你的目标，那么就使用一些工具，比如分析器来找出原因。
• 优化剖析器所确定的最糟糕的子系统。保持对每个更改的分析，以便清楚地了解每个更改对性能的影响。
• 重复三件事中的一件，直到有一件事情发生：(1)你达到了目标，然后把软件发送出去；(2)你把目标向下修正到你能达到的目标；或者(3)你的项目被取消了，因为你无法达到你的目标。

这和你解决任何其他工程问题是一样的，比如为这个特性添加一个功能设定的客户目标，跟踪在实现方面的进展，通过仔细的调试分析修复问题，一直迭代直到你发布或失败。性能是一个特点。

对复杂的现代系统的性能分析需要纪律和专注于坚实的工程原理，而不是一个小范围适用于琐碎或不现实情况的技巧包。我从来没有通过应用技巧和技巧来解决现实世界的性能问题。

Answer 2

找个好的侧写员。

即使没有一个好的分析器，也不要费心去优化C#(真的，任何代码)。实际上，手头有一个采样和一个跟踪分析器非常有帮助。

如果没有一个好的分析器，您可能会创建错误的优化，最重要的是，优化那些从一开始就不是性能问题的例程。

轮廓的前三个步骤应该是：(1)度量，(2)度量，然后(3)度量.

Answer 3

优化准则：

1. 除非你需要，否则不要这样做。
2. 如果用新硬件代替开发人员来解决问题更便宜，就不要这么做
3. 不要这样做，除非您可以测量生产等效环境中的变化。
4. 除非你知道如何使用CPU，否则不要这么做。

   和

   内存分析器
5. 如果这样做会使您的代码不可读或无法维护，请不要这样做。

由于处理器的速度越来越快，大多数应用程序的主要瓶颈不是CPU，而是带宽：片外内存带宽、磁盘带宽和网络带宽。

从远端开始：使用YSlow来了解为什么您的网站对于最终用户来说是缓慢的，然后向后移动并修复您的数据库访问不太宽(列)和不太深(行)。

在非常罕见的情况下，为优化CPU使用做任何事情都是值得的，请注意不要对内存使用产生负面影响：我看到了“优化”，开发人员试图使用内存来缓存结果以节省CPU周期。净效果是减少可用内存来缓存页面和数据库结果，这使得应用程序运行速度慢得多！(见关于测量的规则。)

我也看到过这样的情况：一种“愚蠢”的非优化算法击败了“聪明”优化算法。千万不要低估编译器编写人员和芯片设计者在将“低效”循环代码转化为超级高效代码方面的作用，这些代码完全可以在芯片上的内存中通过流水线方式运行。你的“聪明”的基于树的算法有一个未包装的内循环反算，你认为它是“有效的”，它可以被击败，仅仅是因为它在执行过程中没有停留在芯片上的内存中。(见关于测量的规则。)