在我正在进行的当前项目中,我遇到了一段似乎过于夸张的代码。我考虑重写它以避免内存中的对象超出需要,并且难以决定重构的性能是否值得花时间,以及当前设计是否会影响应用程序生命周期中的任何阶段的性能因此需要改变。
我意识到我没有回答这些问题的知识。我需要哪些知识来准确评估代码设计的性能?有谁知道有关C#/ Java内部工作的任何有用的资源有助于我的理解?
答案 0 :(得分:6)
有大量的信息,特别是通过研究MSDN - 但是......
您真正知道是否需要花时间重构的唯一方法是分析此代码。如果它在内存或运行时方面膨胀,您可能需要花时间重构它。如果它运行得很快,并且实际上并没有像你期望的那么多,那么收益可能不值得付出努力。
仅凭代码设计永远不够 - 大多数情况下,如果您根据设计预测性能模式,您的预测将是错误的。是的,有些情况下代码显然设计得很糟糕,但大多数情况下,实际问题的(小)部分并不是您希望问题存在的部分 - 它通常是某些其他小部分代码你永远不会期待...
答案 1 :(得分:2)
好问题! CLR Perf架构师Vance Morrison写了一篇2篇MSDN文章来准确地解决这个问题 检查出来
http://msdn.microsoft.com/en-us/magazine/cc500596.aspx http://msdn.microsoft.com/en-us/magazine/cc507639.aspx
希望这有帮助 感谢
答案 2 :(得分:2)
答案 3 :(得分:1)
只有在你理解它并且维持它将成为一场噩梦时才重写它。如果您仅出于性能原因进行重写,除非您确定它确实导致了性能问题,否则请不要重写。
答案 4 :(得分:1)
我同意Reed和DanDan,这有点像切线,但我喜欢做的一件事是使用我们现有的(N)单元测试框架为我们系统中重要或大量使用的部分设置压力测试。通过这种方式,您可以定义最低可接受的性能级别,然后查看代码是否适合任务,如果不是,则查看重构。
通常我们将Assembly.Tests.dll与Assembly.Stress.Tests.dll一起使用,压力测试通常具有小型,中型,大型和大型数据范围,每个数据都有自己的最大时间限制。这种方法主要是针对性能而不是内存使用。
假设您保留测试记录,例如通过持续集成服务器,您将获得长期性能配置文件。此外,我们不会对CI构建进行压力测试,只需对夜间构建进行压力测试。
答案 5 :(得分:0)
“......我遇到了一段似乎过于夸张的代码......”
我的建议是与最初编写代码的开发人员或团队中可能熟悉该代码的其他人交谈。我不知道什么是“过分夸大”意味着没有看到你所看到的东西。
这可能意味着重构是一种秩序。如果是这种情况,你可以做的一件事就是开始为它编写单元测试,以便更多地了解代码并准备重构。熟悉课程的作用,输入的来源,输入的范围,行为方式,抛出的异常,与之合作的人等等。你会学到很多关于课程/包的内容以及何时你会有一个很好的单位测试安全网来证明你所做的改变不会破坏它。即使你从未真正重构过课程,努力也会有所帮助。
但要小心。对象创建不再是非常昂贵的Java;我敢打赌,C#至少也是如此。如果没有数据支持内存或性能问题,请不要假设您可以通过您的直觉或经验发现这样的事情。