我总是需要考虑表现吗?

一般来说,痴迷于性能或优化是软件开发中通往邪恶的道路。通常,只有大约5%(或更少!)的代码对整个系统的性能有任何影响。首先,作为大多数项目的软件开发人员,你的主要目标是获得正确可靠的功能,当然还有系统的可维护性。然后,一旦实施并正常工作,您就可以评估性能,找出瓶颈所在,并相应地对其进行优化,以实现您的总体目标。

一个洞穴

这个 Knuth quote (“我们应该忘记小效率,大约97%的情况下:过早优化是万恶之源”)可能适用。

当你开车时,你是否经常有意识地检查你的车离路边有多近?如果你有足够的驾驶经验,你就会学会知道它的边缘在哪里,以及如何在不撞到附近东西的情况下驾驶和停车。

通过试错和提问获得类似的编程性能直觉/经验很重要,但你不应该花时间不断地反复检查自己。

不,说真的。有些应用程序永远不会有足够的用户来保证数据库中的基本索引和键关系。它们不需要调整代码的内部循环。例如,工作组规模的应用程序。

关于性能。但是,有许多应用程序永远不会看到足够的用户,以至于系统资源甚至会注意到你的存在。

浪费金钱和精力 .

我认为这里有两个相互矛盾的谚语。

1:过早优化是万恶之源。

引用Knuth的“过早优化”。“.vevil”是编写草率和缓慢代码(正确与否)的糟糕论据。

1. 你需要指标来优化。
3. 你只优化了重要的代码子集。

如果你正在编写一个谷歌搜索引擎替代品,并且你预计会有很多流量,那么你就要想办法让搜索尽可能快。

假设我们满足上述1、2和3:

如果你需要进行架构或其他重大更改,那么完成90%可能也为时已晚。编写的代码越多,就越难改变事情,即使只是因为有更多的代码需要考虑。你需要不断确保你的应用程序在需要的时间和地点运行。

再者,如果你有编写良好的单元测试,你应该能够将性能测试作为这些测试的一部分。

代码,然后优化,而不是同时优化。

性能不是可以

如果它正常工作并且具有显著和明显的延迟, 不要优化 .改为个人资料。应用程序的大部分时间都将花在一个“热”循环中,而哪个循环很少是直观的。你需要真实的测量和科学来告诉你发生了什么。一旦你有了个人资料数据,你的优化任务应该从小到大:

1. 架构优化。应用程序的整体结构是否是效率低下的根源?

2. 算法优化:您是否使用了正确的数据结构?您是否以正确的方式访问它们?你的应用程序大部分时间都花在写作上,还是花在阅读上?优化该问题的答案。

3. 最后的手段。微观优化。简化热循环,或展开一些循环。达夫的装置。在确定无法对其他两个级别进行进一步改进之前,不要在这个级别进行优化,而且你仍然没有达到你的性能目标。这种级别的优化很可能会破坏垃圾,使你的应用程序更难增长,更脆弱,所以除非你真的必须这样做,否则不要这样做。

我再次强调,不要浪费时间优化任何看起来效率低下的随机代码。优化时间是一项重大投资。在你把时间押在失败者身上之前,你应该有证据支持你。

您应该优化性能 之后

我什么时候需要考虑性能,什么时候不需要?

只要你不考虑正确性,你就可以考虑性能。 :-)

然而,大多数时候,你的想法将是“

对我来说,当我处理图像操作、多个超过10万的大型sql查询或循环时,我会考虑优化。否则我不会,除非我看到它工作时很慢。

1. 将从头到尾贯穿主要用例的最小版本放在一起。在这一步中,我主要关注的是简单性和任何适用模式的良好实现。

3. 通常,当#2完成时,事情的表现令人满意,但测试会确认这一点或不确认;并指出需要进行优化的位置(通常很少)。

我越来越发现,我在第一阶段和第二阶段思考高效设计的任何时间都会破坏简单性,而简单性在当时是首要的。

正如其他人所说,在你知道问题之前进行优化是浪费时间。我最近编写了一些经过大量优化的代码,我的大部分时间都花在了删除优化上!问题在于,它使得添加关键功能变得不可能。

只要它运行正常 30分钟相当于16小时。

这通常归结为要求。在某些情况下,您对响应时间等有非常严格的非功能要求。在这些情况下,你应该额外努力来调整你的代码、过程等。

但根据经验法则(IMHO),您应该根据围绕可靠性和可维护性的最佳实践构建代码,然后围绕性能进行一轮特定的测试。这样,您将知道您将只调整实际影响性能的代码位。

意思是——如果它不会得到大量使用,那么就要相应地担心。不要极度懒惰或效率低下,也不要每次都过分沉迷于算法涅盘。通常最好编写最简单的代码,并根据需要使其更快/优化。与此同时,任何开发人员都可以编写简单的代码,这值得考虑。

如果你看到它的重要性在增加,现在你知道要多想想,因为它会在后面咬你。

我们无法预测每一个问题。我努力做好设计,让问题吸引我的注意力。

答案1:

许多人正确地说“不要考虑性能,以后再优化”,但请记住 他们有单元测试 ,这一次更难了,因为算法更复杂。

能 将优化推迟到以后,但你必须确保你为此做好了准备。如果你没有一个可行的计划来稍后进行优化(单元测试、分析代码的工具),那么你最好现在考虑性能,因为它以后会对你造成更大的伤害。

答案2:

O(n^n) 时间。如果你 您将拥有大量数据集,然后立即进行优化。

答案3:

不久前,我厌倦了PHP中的瑕疵,并试图修复其中的一些。我写了一个涉及基类的框架 必须继承。它使用了方法和属性重载、反射以及几乎所有其他高级功能来使其工作。然后我继续在一个大型项目中使用它,使用我自己的框架功能,而不是像这样的基本语言功能 isset() 和 static

如果你想尝试扩展语言本身,你需要考虑性能 现在 因为你必须重写 每件事 如果你不能优化它。C有一个零成本的宏观系统,那就去吧。Javascript没有这样的系统,在编写一个你想在任何地方使用的新对象继承系统时都要非常小心。

最好编写代码,然后确定从优化中受益最大的关键领域。

也就是说,性能 是 这很重要,但可能会导致毁灭。

为什么这会成为一个问题?这怎么可能是一个只在重新执行时才会出现的问题呢?如果这只是购买该设备的问题,那么它肯定会在测试中被发现!

我的猜测是,这是由于过早的优化。当你点击“购买单位”按钮时,开发商不想为所有单位都购买,而是像银行一样制作了一个盖帽,所以当一个单位被创建时,它会从银行取出盖帽,当它死亡时,盖帽会被放回银行。当然,这更具表现力,但一个小错误就会让整个银行措手不及。

在很多情况下,最好标记一个

// todo: performance could be better
// try doing xyz if we need to improve it

因为高性能版本需要更多时间,并增加了代码的维护成本。

您应该担心的性能是向客户提供令人满意并满足其需求的解决方案。到达发布日期的速度通常更重要。

在某些情况下,一般性能很重要,例如嵌入式系统,但这应该被称为预先限制,并且是在编写代码之前应该了解的特殊情况。

通常,如果你开始谈论性能,其他人就会开始谈论优化,你可能会说这很早,因为性能和优化不是一回事。

使最优化

或 后天的 后天的 这应该被视为优化,现在做还为时过早 由因及果 某种表演工作是合适的,或者更合适 由因及果 .

努力做对的主要事情 由因及果 你的基本方法是否合理。这里经常给出的一个例子是算法的时间复杂度,但我不同意。在O(1)或O(n log n)中做某事并不总是比在O(n)中好。当n为1时,O(n)时间与O(1)时间相同,当n为0时更快,在许多情况下,具有0或1项的数据集可能很常见。更重要的是,时间复杂度表示法故意忽略了低阶项和常数。实际上O(n)时间意味着kn+c(以及可能的其他低阶项),而O(1)时间意味著k+c, 如果该算法本身位于循环内,则O(n)可能会大大击败O(1)。

这里要考虑的是时间复杂性。如果是这样,那么是时候看看O(n)因缺乏开销而击败O(1)的情况是否适用,或者是否应该采用更常见的情况,即O(n 是否应该忽略这里的时间复杂性,只做读起来更自然的事情 例如,时间复杂度竞争的一个常见情况是,是使用列表进行搜索,还是使用基于哈希的集合进行查询。然而,对于大多数库,每个库的代码看起来都不同,因此会有一个更好地描述意图的库,这是在性能不关键的情况下使用的库。

重要的 由因及果 虽然关于这里的表现,但在这个阶段是否值得考虑表现。

因此,我们需要从一开始就进行一些思考,尽管我们不需要在这个阶段解决所有问题。

一开始另一个合理的想法是 由因及果 ,但粒度更细。它只是花了一点时间来合理地相信,不去更详细地思考性能是可以的。

另一个合理的想法是 我非常确定这一部分的性能将是至关重要的,但我还无法衡量不同方法的影响 在这里,你已经决定优化可能是必要的,但现在瞄准最佳状态确实为时过早。但是,您可以通过设置功能边界来奠定基础,这样您就可以更容易地更改可疑关键部分的实现,或者可能将时间记录代码放入该函数中,特别是在调试构建时,特别是如果它离调用公共方法很远(因此它不等同于在外部测试中进行时间记录)。你什么都没做 由因及果

另一件值得思考的事情是,是否应该以多线程的方式完成某事,但请注意,这里有三个合理的想法;以及 这需要多重威胁 和 这不需要是多线程的 还有 这 可能 需要多线程

最后,你需要考虑在事后衡量绩效的能力,以及你需要多久衡量一次。

另一个重要的情况是,您将无法轻松获得有关代码使用方式的信息。如果你正在编写一个在单个站点中使用的应用程序,你将能够很好地衡量这一点。如果你正在编写一个将被分发的应用程序,这会变得更加困难。如果你正在编写一个将在多个不同应用程序中使用的库,那么它就更难了。在后一种情况下,认为YAGNI变得更弱的论点;也许有人真的需要这种缓慢的方法得到很大的改进,而你对此一无所知。不过,你需要采取的方法并不总是一样的;而一种方法是提前投入工作,使其在这种情况下更具性能(不完全是 由因及果 后天的 由因及果 另一种方法是简单地记录特定方法必然是昂贵的,并且调用代码应该记忆或以其他方式优化自己的代码使用它的方式 如果挪用 .

不断地,如果主要是潜意识地,思考绩效很重要,只是对这种想法的适当反应并不总是如此 现在让它跑得更快 .

我在某种程度上不同意这里的观点。

你总是考虑性能,但这种考虑通常是忽略它。看看代码的运行频率。如果答案是“一次”或“很少”,那么性能基本上不是问题。

只有当一段代码要频繁执行时,你才需要注意性能。即使在这种情况下,在分析显示问题之前,您通常也应该只查看例程的O()类。