<分区>
如今，优化似乎是一门失传的艺术。不是有一段时间所有的程序员都从他们的代码中榨取每一丝效率吗？经常在雪中行走五英里时这样做？
本着恢复失传艺术的精神，您知道哪些关于简单(或复杂)更改以优化 C#/.NET 代码的技巧？由于这是一件非常广泛的事情，取决于一个人试图完成什么，它有助于提供提示的上下文。例如:
- 当将多个字符串连接在一起时，请改用
StringBuilder。有关这方面的警告，请参阅底部的链接。
- 使用
string.Compare 来比较两个字符串，而不是像 string1.ToLower() == string2.ToLower()
目前的普遍共识似乎是衡量是关键。这种做法没有捕获要点:测量并不能告诉您出了什么问题，或者如果您遇到瓶颈该怎么办。我遇到过一次字符串连接瓶颈，不知道该怎么办，所以这些提示很有用。
我什至发布这篇文章的目的是为常见的瓶颈提供一个位置，以及如何在遇到它们之前避免它们。它甚至不一定是任何人都应该盲目遵循的即插即用代码，而是更多地了解应该考虑性能，至少在某种程度上，以及需要注意一些常见的陷阱。
不过，我知道了解提示为何有用以及应该在何处应用可能会很有用。对于 StringBuilder 提示，我在很久以前在 here on Jon Skeet's site 找到了帮助。 .
It seems like optimization is a lost art these days.
曾经有一天，显微镜的制造被当作一门艺术来实践。光学原理知之甚少。零件没有标准化。镜筒、齿轮和镜头必须由高技能 worker 手工制作。
如今，显微镜是作为一门工程学科生产的。物理学的基本原理非常容易理解，现成的部件随处可见，显微镜制造工程师可以就如何最好地优化他们的仪器以完成其设计任务做出明智的选择。
性能分析是一门“失传的艺术”，这是一件非常非常好的事情。这种艺术被作为一门艺术来实践。优化应该按照它的本质来处理:工程问题可以通过仔细应用可靠的工程原理来解决。
多年来，我已多次被问及我的“提示和技巧”列表，人们可以使用这些提示和技巧来优化他们的 vbscript/他们的 jscript/他们的事件服务器页面/他们的 VB/他们的 C# 代码。我总是抵制这一点。 强调“提示和技巧”完全是接近性能的错误方法。这种方法会导致代码难以理解、难以推理、难以维护，而且通常不会比相应的直接代码。
处理性能的正确方法是像对待任何其他问题一样将其作为工程问题来处理:
- 设定有意义、可衡量、以客户为中心的目标。
- 构建测试套件，以在现实但受控且可重复的条件下针对这些目标测试您的表现。
- 如果这些套件表明您没有达到目标，请使用分析器等工具找出原因。
- 对分析器识别为性能最差的子系统进行优化。持续分析每项更改，以便您清楚地了解每项更改的性能影响。
- 重复直到发生以下三种情况之一:(1) 您实现了目标并发布了软件，(2) 您将目标向下修改为可以实现的目标，或者 (3) 您的项目因无法实现您的目标而被取消目标。
这与您解决任何其他工程问题(例如添加功能)一样——为该功能设定以客户为中心的目标，跟踪可靠实现的进度，通过仔细的调试分析解决您发现的问题，不断迭代，直到你发货或失败。 性能是一项功能。
对复杂的现代系统进行性能分析需要遵守纪律并专注于扎实的工程原理，而不是一堆只适用于微不足道或不切实际情况的技巧。我从来没有通过应用提示和技巧解决过现实世界的性能问题。