提前规划效率与提前优化

我通常要做的是应用那些不需要花费任何代价(或者几乎不需要花费任何代价)的优化。我也会留意那些不能很好地扩展并且经常被调用的算法。除此之外,在软件运行之前我不会进行优化,并且我有机会启动分析器。只有这样,我才会投入大量时间进行优化。

在早期的设计和架构级别进行优化。稍后在实施级别进行微观优化。

您需要了解您所做的设计决策的性能成本,这在以后很难改变。实现经常可以在稍后进行调优,这就是为什么在您知道这是一个问题之前不值得这样做的原因。

专注于编写完全按照预期执行的代码,并且只编写所需的次数。优化干净、优雅的代码通常很简单。

理想情况是先进行概要分析,然后在必要时进行优化,但这不适用于设计;当您有任何可执行的概要分析时,更改设计将非常昂贵。因此,设计必须注重效率的提高。通常这意味着要预先草拟出有效的算法,并保持足够的灵活性,以便以后更改。(这通常最好是在功能分离良好的情况下完成,尽可能保持模块独立,这是出于其他原因的良好设计实践。)

通常,在设计阶段,您会很清楚性能有多重要。如果需要,可以从一开始就设计性能(不包括代码级优化)。

在两种其他类似的实践中进行选择时,也有高效编码习惯的发展。例如,在C++中,键入是值得的。 ++i 而不是 i++ 因为这是一件微不足道的事情,有时效率会大大提高。

除此之外的任何事情都应该等到(a)很明显,提高性能会有回报,(b)你知道热点在哪里。

我会说,修改“如果你赢了就是战术,如果你输了就是作弊”

如果成功的话,这就是“效率规划”,如果失败的话,这就是“过早的优化”。

我喜欢 this guy 的配方。

1. 通过使用更多 明智的整体方法。
2. 通过减少代码优化 奇怪的。
3. 通过使 代码更奇怪。

前两个是你的第二点。他的3是你的1,是万恶之源。他是对的,使代码“更奇怪”的优化使代码变得更复杂和更难理解,从而导致更多的错误和维护难题。

在不增加大量时间或精力的情况下,第一次尽可能地构建它。那就让它为你的注意力而战吧。

我也会: 从一开始就使用适当和有效的数据结构 . 这确实涵盖了很多方面:

1. 知道所有标准容器是如何工作的,它们擅长什么,它们擅长什么。SortedDictionary插入和搜索速度快,但删除速度差。LinkedList添加和删除速度快,但搜索能力差,等等。
2. 知道你的瓶颈在哪里。它将是CPU、磁盘、内存、图形、IO、网络等。知道如何有效地利用每个区域,每个区域都需要不同的设计模式。这实际上也取决于正在开发的应用程序——对于UI响应性,对于数据处理良好的磁盘缓存,需要关注的核心指标是什么。
3. 多重阅读。如果应用程序将扩展到多个核心,则需要在开发生命周期的早期就决定是否需要这样的系统。后期的螺栓穿线成本要高得多。

有些答案你将从经验中知道,有些需要研究,但它永远不会是猜测工作。

它应该纯粹是投资回报分析。如果你能花点精力来设计优化,并获得巨大的性能回报,那么就去做吧。渐渐地,你会发现付出努力的回报不再有意义。

有一个基本事实:

无法优化无法测试的内容

因此,正如其他人所说,尤其是对性能优化的WRT,您必须编写代码,然后才能测试它。更重要的是,在大量的代码中,一种算法通常是最快的,但是考虑到它与其他代码的相互关系,它要么是一种浪费时间的无用优化,要么比选项2、3……慢。

然而,你可以利用一些知识,特别是在概念层面上,帮助你在全球范围内“预优化”你的设计。

不幸的是,这是一个没有真正结束的辩论。

尤其是数据库不容易重构,而且通常是系统中最大的瓶颈,因为设计人员认为他们在设计时不应该关心性能。这是短视。有许多已知的数据库优化,几乎所有时间都会更快。在设计和初始编码中不使用它们来避免“过早优化”是愚蠢的。例如,在SQL Server中,光标几乎永远不会(除非您正在查找汇总)比基于集合的查询执行得更好。编写光标而不是基于集的查询速度并不快(一旦理解了基于集的查询),因此没有理由从基于光标的代码开始。派生表的副查询也一样。为什么写你知道90%的代码会比写相同时间的其他代码慢?

选择使用一个稍后很难进行性能优化的工具也是一个短视的决定,因此在考虑您打算如何访问数据库时,这应该是您考虑的一部分。

任何对数据库进行编码或设计的人,都应该花些时间来了解其特定类型的数据库的性能调整。事先知道如何编写一个可搜索的查询,以及应该使用哪些类型的索引,以及常见的瓶颈类型将有助于您第一次更好地完成工作。

这就是计划发挥作用的地方。如果你有一个很好的计划,并且有一个很好的写作模型,那么优化应该只发生在文章中。如果你发现自己需要优化大量的代码,你很可能从一开始就做了一些错误的事情。

很多这样的事情也会伴随着经验和从事类似的工作。一般来说,你唯一需要写一些需要优化的东西的时候,就是你在写那些你以前从未用过的东西。优化发生在计划阶段和项目后阶段IMO。

代码除了提供基本功能外,还有三个特点 软件开发人员需要提供:

1. 性能
2. 维修性
3. 鲁棒性

一个空闲的代码将提供这三个。 在资源有限的情况下,对哪部分代码的调用应该进行优化 需要评估的内容。 以牺牲他人为代价优化其中一个是危险的,而且应该 尽量避免。

我想说的中间立场是在编写代码时要记住已知的低效率,但如果这意味着在初始开发中需要额外的时间或增加复杂性,就不要过早地进行优化。

我的理论是,“编写简单的工作代码,然后根据测试需要进行优化。”