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

这里有大量的信息,特别是通过对msdn的研究,但是…

唯一真正知道是否需要花时间重构的方法是对代码进行概要分析。如果它在内存或运行时间方面膨胀了,您可能需要花些时间来重构它。如果它运行得很快,而且实际占用的内存没有您预期的那么多,那么所获得的收益可能不值得您付出努力。

单靠代码设计是远远不够的——大多数情况下,如果您根据设计来投影性能模式,那么您的投影将是错误的。是的,有些情况下代码的设计显然很糟糕,但大多数情况下,实际问题的(小)部分并不是您期望问题存在的部分-它通常是一些您从未期望过的其他小代码…

好问题! clr性能架构师vance morrison写了一篇2 msdn的文章来准确地解决这个问题。 检查他们

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

希望这有帮助 谢谢

掌握正确的知识不是问题。

任何说他们只是“知道”在特定代码中花费时间的人,除非他们通过分析或 sampling , 只是猜测而已 .

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

每个人都知道,但无论如何他们都会这么做。

只有当你无法理解和维护它时,才重写它,这将是一场噩梦。如果只是出于性能方面的原因而重写,请不要这样做,除非您确信这会导致性能问题。

我同意Reed和Dandan的观点,这有点相切,但我喜欢做的一件事是使用我们现有的(n)单元测试框架为系统的重要或大量使用的部分设置压力测试。这样,您就可以定义可接受的最低性能级别,然后查看代码是否能够完成任务,如果不能完成任务,则查看重构。

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

假设您保存了测试的日志(例如通过持续集成服务器),那么您将获得一个长期的性能概要。此外,我们不为我们的CI构建运行压力测试,只运行夜间构建。

“…我遇到了一段代码,这段代码似乎有些夸张了……”

我的建议是与最初编写代码的开发人员或团队中可能非常了解代码的其他人交谈。我不知道“过度”是什么意思,如果没有看到你所看到的。

这可能意味着重构是一个命令。如果是这样的话,您可以做的一件事就是进一步了解代码并为重构做好准备,开始为它编写单元测试。熟悉类的功能、输入的来源、输入的范围、行为、抛出的异常、它与谁合作等等。您将学到很多关于该类/包的知识,完成后,您将拥有一个很好的单元测试安全网,以证明所做的更改不会破坏它。即使你从未真正重构过这个类,这项工作也会有所帮助。

但要小心。对于Java来说,对象创建不再昂贵了,我敢打赌C语言至少也会这么做。如果没有数据来支持内存或性能问题,不要以为你能凭直觉或经验发现这样的问题。