C++代码优化经验总结

上传人:秋**** 文档编号:224779579 上传时间:2021-12-16 格式:DOCX 页数:32 大小:21.04KB
返回 下载 相关 举报
C++代码优化经验总结_第1页
第1页 / 共32页
C++代码优化经验总结_第2页
第2页 / 共32页
C++代码优化经验总结_第3页
第3页 / 共32页
亲,该文档总共32页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《C++代码优化经验总结》由会员分享,可在线阅读,更多相关《C++代码优化经验总结(32页珍藏版)》请在金锄头文库上搜索。

1、C+代码优化经验总结优化是一个非常大的主题,本文并不是去深入探讨性能分析理论,算法的效率,况且我也没有这个能力。我只是想把一些可以简单的应用到你的C+代码中的优化技术总结在这里,这样,当你遇到几种不同的编程策略的时候,就可以对每种策略的性能进行一个大概的估计。这也是本文的目的之所在. 目录: 一. 优化之前 二. 声明的放置 三. 内联函数 四. 优化你的内存使用 五. 速度优化 六. 最后的求助 一. 优化之前 在进行优化之前,我们首先应该做的是发现我们代码的瓶颈(bottleneck)在哪里。 然而当你做这件事情的时候切忌从一个debug-version进行推断,因为debug-versi

2、on中包 含了许多额外的代码。一个debug-version可执行体要比release-version大出40%。那些额 外的代码都是用来支持调试的,比如说符号的查找。大多数实现都为debug-version和rele ase-version提供了不同的operator new以及库函数。而且,一个release-version的执行 体可能已经通过多种途径进行了优化,包括不必要的临时对象的消除,循环展开,把对象 移入寄存器,内联等等。 另外,我们要把调试和优化区分开来,它们是在完成不同的任务。 debug-version 是 用来追捕bugs以及检查程序是否有逻辑上的问题。release-v

3、ersion则是用来做一些性能上 的调整以及进行优化。 下面就让我们来看看有哪些代码优化技术吧! 二. 声明的放置 程序中变量和对象的声明放在什么位置将会对性能产生显著影响。同样,对postfix和 prefix运算符的选择也会影响性能。这一部分我们集中讨论四个问题:初始化v.s 赋值, 在程序确实要使用的地方放置声明,构造函数的初始化列表,prefix v.s postfix运算符 。 (1) 请使用初始化而不是赋值 在C语言中只允许在一个函数体的开头进行变量的声明,然而在C+中声明可以出现在 程序的任何位置。这样做的目的是希望把对象的声明拖延到确实要使用它的时候再进行。 这样做可以有两个好

4、处:1. 确保了对象在它被使用前不会被程序的其他部分恶意修改。如 果对象在开头就被声明然而却在20行以后才被使用的话,就不能做这样的保证。2. 使我们 有机会通过用初始化取代赋值来达到性能的提升,从前声明只能放在开头,然而往往开始 的时候我们还没有获得我们想要的值,因此初始化所带来的好处就无法被应用。但是现在 我们可以在我们获得了想要的值的时候直接进行初始化,从而省去了一步。注意,或许对 于基本类型来说,初始化和赋值之间可能不会有什么差异,但是对于用户定义的类型来说 ,二者就会带来显著的不同,因为赋值会多进行一次函数调用-operator =。因此当我 们在赋值和初始化之间进行选择的话,初始化

5、应该是我们的首选。 (2) 把声明放在合适的位置上 在一些场合,通过移动声明到合适的位置所带来的性能提升应该引起我们足够的重视 。例如: bool is_C_Needed(); void use() C c1; if (is_C_Needed() = false) return; /c1 was not needed /use c1 here return; 上面这段代码中对象c1即使在有可能不使用它的情况下也会被创建,这样我们就会为它付 出不必要的花费,有可能你会说一个对象c1能浪费多少时间,但是如果是这种情况呢:C c11000;我想就不是说浪费就浪费了。但是我们可以通过移动声明c1的位置

6、来改变这种情 况: void use() if (is_C_Needed() = false) return; /c1 was not needed C c1; /moved from the blocks beginning /use c1 here return; 怎么样,程序的性能是不是已经得到很大的改善了呢?因此请仔细分析你的代码,把声明 放在合适的位置上,它所带来的好处是你难以想象的。 (3) 初始化列表 我们都知道,初始化列表一般是用来初始化const或者reference数据成员。但是由于 他自身的性质,我们可以通过使用初始化列表来实现性能的提升。我们先来看一段程序: class

7、 Person private: C c_1; C c_2; public: Person(const C& c1, const C& c2 ): c_1(c1), c_2(c2) ; 当然构造函数我们也可以这样写: Person:Person(const C& c1, const C& c2) c_1 = c1; c_2 = c2; 那么究竟二者会带来什么样的性能差异呢,要想搞清楚这个问题,我们首先要搞清楚二者 是如何执行的,先来看初始化列表:数据成员的声明操作都是在构造函数执行之前就完成 了,在构造函数中往往完成的只是赋值操作,然而初始化列表直接是在数据成员声明的时 候就进行了初始化,因此

8、它只执行了一次copy constructor。再来看在构造函数中赋值的 情况:首先,在构造函数执行前会通过default constructor创建数据成员,然后在构造函 数中通过operator =进行赋值。因此它就比初始化列表多进行了一次函数调用。性能差异 就出来了。但是请注意,如果你的数据成员都是基本类型的话,那么为了程序的可读性就 不要使用初始化列表了,因为编译器对两者产生的汇编代码是相同的。 (4) postfix VS prefix 运算符 prefix运算符+和比它的postfix版本效率更高,因为当postfix运算符被使用的时 候,会需要一个临时对象来保存改变以前的值。对于

9、基本类型,编译器会消除这一份额外 的拷贝,但是对于用户定义类型,这似乎是不可能的。因此请你尽可能使用prefix运算符 。 三. 内联函数 内联函数既能够去除函数调用所带来的效率负担又能够保留一般函数的优点。然而, 内联函数并不是万能药,在一些情况下,它甚至能够降低程序的性能。因此在使用的时候 应该慎重。 1我们先来看看内联函数给我们带来的好处:从一个用户的角度来看,内联函数看起来和 普通函数一样,它可以有参数和返回值,也可以有自己的作用域,然而它却不会引入一般 函数调用所带来的负担。另外,它可以比宏更安全更容易调试。 当然有一点应该意识到,inline specifier仅仅是对编译器的建议

10、,编译器有权利忽 略这个建议。那么编译器是如何决定函数内联与否呢?一般情况下关键性因素包括函数体 的大小,是否有局部对象被声明,函数的复杂性等等。 2那么如果一个函数被声明为inline但是却没有被内联将会发生什么呢?理论上,当编译 器拒绝内联一个函数的时候,那个函数会像普通函数一样被对待,但是还会出现一些其他 的问题。例如下面这段代码: / Time.h #include #include using namespace std; class Time public: inline void Show() for (int i = 0; i10; i+) couttime(0)endl; ;

11、 因为成员函数Time:Show()包括一个局部变量和一个for循环,所以编译器一般拒绝inline ,并且把它当作一个普通的成员函数。但是这个包含类声明的头文件会被单独的#include 进各个独立的编译单元中: / f1.cpp #include Time.hj void f1() Time t1; t1.Show(); / f2.cpp #include Time.h void f2() Time t2; t2.Show(); 结果编译器为这个程序生成了两个相同成员函数的拷贝: void f1(); void f2(); int main() f1(); f2(); return 0;

12、当程序被链接的时候,linker将会面对两个相同的Time:Show()拷贝,于是函数重定 义的连接错误发生。但是老一些的C+实现对付这种情况的办法是通过把一个un-inlined函 数当作static来处理。因此每一份函数拷贝仅仅在自己的编译单元中可见,这样链接错误 就解决了,但是在程序中却会留下多份函数拷贝。在这种情况下,程序的性能不但没有提 升,反而增加了编译和链接时间以及最终可执行体的大小。 但是幸运的是,新的C+标准中关于un-inlined函数的说法已经改变。一个符合标准C+ +实现应该只生成一份函数拷贝。然而,要想所有的编译器都支持这一点可能还需要很长时 间。 另外关于内联函数还

13、有两个更令人头疼的问题。第一个问题是该如何进行维护。一个 函数开始的时候可能以内联的形式出现,但是随着系统的扩展,函数体可能要求添加额外 的功能,结果内联函数就变得不太可能,因此需要把inline specifier去除以及把函数体 放到一个单独的源文件中。另一个问题是当内联函数被应用在代码库的时候产生。当内联 函数改变的时候,用户必须重新编译他们的代码以反映这种改变。然而对于一个非内联函 数,用户仅仅需要重新链接就可以了。 这里想要说的是,内联函数并不是一个增强性能的灵丹妙药。只有当函数非常短小的 时候它才能得到我们想要的效果,但是如果函数并不是很短而且在很多地方都被调用的话 ,那么将会使得

14、可执行体的体积增大。最令人烦恼的还是当编译器拒绝内联的时候。在老 的实现中,结果很不尽人意,虽然在新的实现中有很大的改善,但是仍然还是不那么完善 的。一些编译器能够足够的聪明来指出哪些函数可以内联哪些不能,但是,大多数编译器 就不那么聪明了,因此这就需要我们的经验来判断。如果内联函数不能增强行能,就避免 使用它! 四. 优化你的内存使用 通常优化都有几个方面:更快的运行速度,有效的系统资源使用,更小的内存使用。 一般情况下,代码优化都是试图在以上各个方面进行改善。重新放置声明技术被证明是消 除多余对象的建立和销毁,这样既减小了程序的大小又加快了运行速度。然而其他的优化 技术都是基于一个方面-更快的速度或者是更小的内存使用。有时,这些目标是互斥 的,压缩了内存的使用往往却减慢了代码速度,快速的代码却又需要更多的内存支持。下 面总结两种在内存使用上的优化方法: 1 Bit Fields 在C/C+中都可以存取和访问数据的最小组成单元:bit。因为bit并不是C/C+基本的

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 商业/管理/HR > 营销创新

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号