本系列是开源书C++ Best Practises的中文版,全书从工具、代码风格、安全性、可维护性、可移植性、多线程、性能、正确性等角度全面介绍了现代C++项目的最佳实践。本文是该系列的第六篇。
C++最佳实践:
性能
尽量使用前置声明
使用这种声明方式:
而不是这样:
同样也使用于模板:
这种方式可以主动减少编译时间并重新构建依赖关系。
注意: 前置声明会阻碍内联和优化,建议在发布版本中使用链接时优化或链接时代码生成。
避免不必要的模板实例化
模板不要随便实例化,实例化过多模板,或者模板代码多于必要的数量,会增加编译代码的大小和构建时间。
更多示例请参考: Template Code Bloat Revisited: A Smaller make_shared
避免递归模板实例化
递归模板实例化可能会给编译器带来很大的负担,并且代码更加难以理解。
分析构建
可以使用Templight工具分析项目的构建时间,它需要花一些时间来构建,但一旦这样做了,可以用来替换clang++。
使用Templight进行构建之后,需要对结果进行分析,templight-tools项目提供了各种方法(建议使用callgrind转换并使用kcachegrind对结果进行可视化)。
隔离频繁更改的头文件
不要包含不需要的头文件
编译器必须处理看到的每个include指令,即使只是在看到#ifndef
include保护符后立即停止,仍然必须打开文件并进行处理。
include-what-you-use是一个可以帮我们确定需要哪些头文件的工具。
减少预处理器的工作
这是“隔离频繁更改的头文件”和“不要包含不需要的头文件”的一般形式。类似BOOST_PP这样的工具可能非常有用,但也给预处理器带来了巨大的负担。
考虑使用预编译头文件
使用预编译头文件可以大大减少大型项目的编译时间,选定的头文件被编译成中间形式(PCH文件),编译器可以更快处理。建议只将经常使用但很少更改的头文件定义为预编译头文件(例如系统头文件和库头文件),以减少编译时间。但必须记住,使用预编译头文件有几个缺点:
预编译头文件不可移植。
生成的PCH文件依赖于机器。
生成的PCH文件可能相当大。
它会破坏头文件依赖关系。由于有预编译头文件,每个文件都有可能包含标记为预编译头文件的每个头文件。因此,如果禁用预编译头文件,可能会导致构建失败。如果需要发布库之类的项目,这可能是个问题。正因为如此,强烈建议在第一次构建时启用预编译头,而在后续构建时将其关闭。
大多数常见的编译器都支持预编译头文件,比如GCC、Clang和Visual Studio。像cotire(cmake的插件)这样的工具可以帮助我们在构建系统中添加预编译的头文件。
考虑使用工具
工具并不意味着可以取代好的设计。
将tmp放在Ramdisk上
详见YouTube视频: https://www./watch?v=t4M3yG1dWho
使用gold链接器
如果是在Linux上,考虑使用GCC的gold链接器(ld.gold)。
参考: gold: Google Releases New and Improved GCC Linker
运行时
分析代码
在不分析代码的情况下,无法真正找到瓶颈在哪里。
简化代码
代码越清晰、越简单、越容易阅读,编译器就越有可能更好的将其实现。
使用初始化列表
通过减少对象复制并调整容器大小,初始化列表能显著提升性能。
减少临时对象
这类代码将阻碍编译器执行move操作……
启用移动(move)操作
move操作是C++11中最受欢迎的特性之一,该操作允许编译器通过移动临时对象从而避免额外的拷贝。
某些代码(例如声明自己的析构函数或赋值操作符或拷贝构造函数)会阻止编译器生成移动构造函数。
对于大多数代码,下面这么一个简单的定义:
...就足够了,不过MSVC2013似乎不支持这段代码。
避免shared_ptr
拷贝
shared_ptr
对象的拷贝成本比想象的要高得多,因为引用计数必须是原子的和线程安全的。这条规则只是再次强调了上面的注意事项: 避免临时对象和过多的对象副本。仅仅因为我们使用了pImpl,并不意味着副本没有代价。
尽可能减少拷贝和重分配
对于更简单的情况,可以使用三元操作符:
使用立即调用的lambda可以简化更复杂的情况。
避免多余的异常
在正常处理期间,内部抛出和捕获的异常会降低应用程序的执行速度。由于调试器会监视和报告每个异常事件,因此还会破坏调试器的用户体验。最好尽可能避免内部异常处理。
抛弃new
我们已经知道不该使用裸内存访问,因此改用unique_ptr
和shared_ptr
,对吧?堆分配比栈分配昂贵得多,但有时不得不用。更糟的是,创建shared_ptr
实际上需要在堆上分配2次。
然而,make_shared
函数可以将其减少为一次。
优先选择unique_ptr
而不是shared_ptr
可能的话,使用unique_ptr
而不是shared_ptr
。unique_ptr
是不可复制的,因此不需要跟踪副本,比shared_ptr
性能更好。另外,类似于shared_ptr
和make_shared
的关系,应该使用make_unique
(C++14或更高版本)来创建unique_ptr
:
目前的最佳实践也建议从工厂函数返回unique_ptr
,然后在必要时将unique_ptr
转换为shared_ptr
。
抛弃std::endl
std::endl
表示刷新操作,等价于"\n" << std::flush
。
限制变量作用域
变量应该尽可能晚声明,最好只在可以初始化对象时声明。减小变量作用域可以减少内存的使用,提高代码效率,并帮助编译器进一步优化代码。
对于C++17及以后版本,考虑在if
和switch
语句中初始化变量:
Github上对此有专门的讨论: https://github.com/lefticus/cppbestpractices/issues/52
优先选择double
类型而不是float
类型,但需要先测试
根据情况和编译器的优化能力,一种可能比另一种更快。选择float
意味着精度较低,并可能由于类型转换而影响性能。在可向量化操作中,如果能够牺牲精度,float
可能更快。
double
是C++中浮点值的默认类型,因此推荐作为默认选项。
参考下面的文章获取更多信息: double or float, which is faster?
优先选择++i
而不是i++
...当语义正确时,前置自增比后置自增更快,因为前置自增不需要创建对象副本。
即使许多现代编译器将这两个循环优化为相同的汇编代码,选择++i
仍然是一种良好的实践。你永远无法确定代码会不会使用不带优化的编译器,因此没有任何理由不这样做。此外,编译器有可能只对整数类型进行优化,而不一定对所有迭代器或其他用户自定义类型进行优化。
总而言之,如果前置自增操作符与后置自增操作符在语义上相同,那么使用前置自增操作符总是更好。
char是char, string是string
看上去区别不大,但是"\n"
必须被编译器解析为const char *
,必须在写入流(或附加到字符串)时对\0
进行范围检查,而'\n'
是已知的单个字符,可以节约许多CPU指令。
如果多次调用效率低下的代码,可能会对性能产生影响,更重要的是,考虑这两种使用情况会让我们更多的考虑编译器和运行时在执行代码时必须做什么。
永远不要用std::bind
std::bind
的开销(包括编译时和运行时)几乎总是比需要的更多,相反,我们只需使用lambda。
了解标准库
正确使用供应商提供的标准库中已经高度优化的组件。
in_place_t
及相关内容
知道如何使用in_place_t
和相关标签高效创建诸如std::tuple
、std::any
和std::variant
等对象。
你好,我是俞凡,在Motorola做过研发,现在在Mavenir做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。
微信公众号:DeepNoMind