EEPW论坛

下面，我整理出了一些自认为有用的条目分享给大家，初学者可以按照这些思路进行学习。我将这些内容分为了三大类别：

• 对象的创建与销毁：主要介绍对象构造与销毁的代价和临时对象那些事。
• 函数调用：主要介绍内联和虚函数及模板相关的知识点。
• 设计：如何设计并编写出更高效的代码。

下面是正文（越下面的内容越有用）：

• 对象的创建与销毁：
• C++中对象的定义会隐式的执行构造函数和析构函数，这是有开销的，对象的生命周期不是无偿的，至少对象的创建和销毁会消耗CPU周期。所以若非必要，不要随便定义对象，要等到需要使用对象的地方再创建它。
• 对象的创建或销毁会触发对父对象和成员对象的递归创建或销毁，要当心复杂层次中对象的复合使用。它们使得创建和销毁的开销更加高昂。
• 对象的拷贝是有开销的，很多时候可以减少拷贝，考虑按引用或者指针传递和返回对象。
  
• RVO可以省去创建和销毁局部对象的步骤，从而改善性能。
• 临时对象会以构造函数和析构函数的形式降低一半的性能。在<op>可能是“+、-、＊”或者“/”的地方，可以考虑使用<op>=运算符消除临时对象。
• 编译器必须初始化被包含的成员对象之后再执行构造函数体。必须在初始化阶段完成成员对象的创建。这可以降低随后在构造函数部分调用赋值操作符的开销。在某些情况下，这样也可以避免临时对象的产生。
• 将构造函数声明为explicit，可以避免隐式转换，一般这块都会被列为项目的编码规范，不符合这个规范是过不了code review的。
• 函数调用：
• 绝大多数的性能优化是靠内联做到的。
• 内联就是用方法的代码来替换对方法的调用。（和宏是不是挺像）
• 内联通过消除调用开销来提升性能，并且允许进行调用间优化。
• 内联也有缺点，尤其是滥用的情况下。内联可能会使代码量变大，而代码量增多后会较原先出现更多的缓存失败和页面错误。
• 为什么说虚函数慢？虚函数的代价在于无法内联函数调用，因为这些调用是在运行时动态绑定的。唯一潜在的效率问题是从内联获得的速度（如果可以内联的话）。
• 模板比继承提供更好的性能。它把对类型的解析提前到编译期间，也可以认为这是没有成本的。

• 设计：
• 软件性能和灵活性之间存在一种基本的平衡，太灵活的设计一般性能都不太好，你的设计只需在当前范围之内足够灵活就可以了。在完成同样的简单工作时，char*有时可以比string对象更有效率。
• 引用计数想必大家都知道，有些场景中没必要使用引用计数，使用的简单的非计数对象即可，但是有些情况下，引用计数是个非常有用且有效的设计，尤其是在下述场景中：
• 目标对象是很大的资源消费者。
• 资源分配和释放的代价很高。
• 高度共享，好多对象共享同一资源
• 最快的代码是从不执行的代码，可做以下思考：
• 你打算使用该计算结果吗？不打算使用就别浪费资源啦
• 你现在需要该结果吗？请在真正需要的时候再进行计算。在一些执行流程中有些结果永远不会被使用，因此不必过早地计算
• 你是否已经知道结果？那可以考虑结果重复使用，而不是每次都做计算
• 有的时候可能无法绕开该计算，此时就必须完成它，那如何加快计算速度？可做以下思考：
• 该计算是否过于通用？上面说过，没必要过度设计，满足需求即可。
• 有些情况下有些考虑使用库调用，有些库调用比较灵活，有些库调用性能比较高，考虑使用高效的算法和数据结构。
• 尽量减少内存管理，这些调用的代价比较高。
• 80-20原则，如果考虑所有可能的输入数据，则可以发现20%的数据在80%时间里出现。因此，应当以牺牲其他不经常出现的场景为代价来提高典型输入的处理速度。
• 缓存、RAM和磁盘访问的速度差异很明显，可能有10倍以上的差异。应该多编写缓存友好的代码。
• 有些计算只有在特定的if-else分支下才需要，所以没必要过早计算，因为有可能它的计算结果不会被用到。
• 定期清理不需要的代码：大型软件往往会变得错综复杂，杂乱不堪。混乱软件的一大特点就是执行失效代码（那些曾经用来实现某个目标，但现在已经不需要的代码）。定期清理失效和僵死代码可以增强软件性能，同时对于软件也是一种维护。
• 考虑利用多处理器：
• 将任务做分解：将大的任务分为小任务，使线程并发地执行这些小任务。
• 缩小临界区：临界区应该只包含关键代码，不直接操作共享资源的代码不要放在临界区内。
• 减小锁粒度：不要用同样的锁来保护所有资源，除非这些资源是同时更新的。
• 读写锁：读多写少可以考虑使用读写锁。
• 伪共享：不要在类定义里把两个使用频度都很高的锁放太靠近，它们共享同一个缓存行可能触发缓存一致性风暴。
• 惊群现象：仔细分析您的锁调用的特征。当锁被释放时，是所有的等待线程都被唤醒还是只唤醒一个线程？唤醒所有线程会威胁到应用的可扩展性。
• 要使用的存储器离处理器越远，访问所需的时间就越长。离处理器最近的是寄存器，虽然容量很少，但是速度很快。对寄存器的优化对程序的性能提升而言是极为有益的。
• 上下文切换的开销巨大，应尽量避免上下文切换。