编程/设计决策如何影响引擎盖下的性能？ [关闭]答案

【问题标题】：How do programming/design decisions affect performance under the hood? [closed]编程/设计决策如何影响引擎盖下的性能？ [关闭]
【发布时间】：2009-07-22 00:03:03
【问题描述】：

在我正在进行的当前项目中，我遇到了一段似乎被夸大的代码。我考虑重写它以避免内存中的对象过多，并且难以决定重构带来的性能优势是否值得花时间，当前设计是否会在应用程序生命周期的任何阶段影响性能，以及因此需要改变。

我意识到我没有回答这些问题的知识。我需要哪些知识来准确评估代码设计的性能？有谁知道 C#/Java 内部工作的任何好的资源可以帮助我理解？

【问题讨论】：

标签： c# performance object

【解决方案1】：

那里有大量的信息，特别是通过研究 MSDN - 但是...

您真正知道是否需要花时间重构的唯一方法是分析此代码。如果它在内存或运行时间方面臃肿，您可能需要花时间重构它。如果它运行得很快，并且实际上并没有像您预期的那样占用太多内存，那么收益可能不值得付出努力。

仅靠代码设计是不够的 - 大多数情况下，如果您根据设计来预测性能模式，那么您的预测将是错误的。是的，在某些情况下，代码的设计显然很糟糕，但大多数情况下，实际问题的（小）部分并不是您期望问题存在的部分——它通常是某处的其他一小段代码你万万没想到……

【讨论】：

【解决方案2】：

好问题！ Vance Morrison，CLR Perf 架构师写了一篇 2 MSDN 文章来准确解决这个问题看看他们

http://msdn.microsoft.com/en-us/magazine/cc500596.aspx http://msdn.microsoft.com/en-us/magazine/cc507639.aspx

希望对您有所帮助谢谢

【讨论】：

【解决方案3】：

这不是拥有正确知识的问题。

任何说他们只是“知道”在特定代码中花费时间的人，除非他们通过分析或sampling 证明了这一点，实际上只是在猜测。

在性能问题上永远不要猜测。

每个人都知道，但他们还是这样做了。

【讨论】：

【解决方案4】：

只有在您无法理解它时才重写它，维护它将是一场噩梦。如果您只是出于性能原因而重写，除非您确定它会导致性能问题，否则不要这样做。

【讨论】：

【解决方案5】：

我同意 Reed 和 DanDan 的观点，这有点切题，但我喜欢做的一件事是使用我们现有的 (N) 单元测试框架为我们系统的重要或频繁使用的部分设置压力测试。这样您就可以定义可接受的最低性能水平，然后查看代码是否能够胜任任务，如果不是，则查看重构。

通常我们有 Assembly.Tests.dll 和 Assembly.Stress.Tests.dll，压力测试通常有小、中、大和巨大的数据样本范围，每个都有自己的最大时间限制。这种方法主要针对性能而不是内存使用。

假设您保留了测试日志，例如通过持续集成服务器，您将获得长期的性能概况。此外，我们不会为 CI 构建运行压力测试，只运行每晚构建。

【讨论】：

【解决方案6】：

"...我遇到了一段似乎被夸大的代码..."

我的建议是与最初编写代码的开发人员或团队中可能很了解代码的其他人交谈。没有看到你所看到的，我不知道“夸大其词”是什么意思。

这可能意味着重构是一个命令。如果是这种情况，您可以做的一件事是了解有关代码的更多信息并为重构做准备，那就是开始为其编写单元测试。熟悉类的功能、输入的来源、输入的范围、行为方式、抛出的异常、与谁协作等。您将学到很多关于该类/包以及何时重新完成后，您将拥有一个很好的单元测试安全网，以证明您所做的更改不会破坏它。即使您从未真正重构过该类，这些努力也会有所帮助。

但要小心。对象创建对于 Java 来说不再那么昂贵了；我敢打赌，C# 至少也是如此。如果没有数据支持内存或性能问题，请不要假设您可以凭直觉或经验发现此类问题。

【讨论】：