1000字范文,内容丰富有趣,学习的好帮手!
1000字范文 > GCC编译优化应用预编译头

GCC编译优化应用预编译头

时间:2021-04-23 14:28:37

相关推荐

GCC编译优化应用预编译头

服务器编译优化记录

对项目编译优化过程中一些思路和脚本工具实现。对内存受限的编译环境有一些帮助。

工具:

/wangxiaobai-dd/GccPrecompiledHeader

环境

32G内存,16核,Makefile,gcc9.2

效果

选择了代码比较多的三个目录进行预编译头优化,进行下述操作。另外: 将小的编译单元合并成大的编译单元也是有效的,如 com.cpp 包含 a.cpp b.cpp , 在com.cpp 中首行也需要 #include "inc.h" ),编译时间从 24min30s左右 降到 14min 左右 ,节省 40%以上编译时间

方法

1. 梳理编译单元

编译时,我们每一个cpp文件将会生成对应的一个.o目标单元,将小的编译单元合并成大的编译单元对编译速度会有显著的提升(已有)。

类似上图,用n.cpp 包含 a.cpp,b.cpp,用m.cpp包含c.cpp,d.cpp,将 4 个编译单元变成 2 个编译单元。

注意,这里我认为应该将修改频率低的文件进行编译单元合并,如果将高修改频率的cpp文件放入合并后的编译单元,那么每次修改这个文件都会导致包含这个大编译单元重新编译。

另外,合并的编译单元尽可能地有一定关联度,可以按照业务功能来划分,或者通过一些数据统计来划分。

2. 应用gcc预编译头

按照图2,当a,cpp b.cpp c.cpp都包含temp.h头文件时,在编译的时候,temp.h会被解析三遍,分别与a,b,c结合生成.o文件。这样我们可以预先对头文件进行编译,生成temp.h.gch文件,这样只需要解析一次temp.h,原来的a.cpp,b.cpp,c.cpp文件仍然include temp.h就好了,只是要最先包含temp.h。

编译时 -H 可以看到cpp文件的依赖信息,应用gch后!temp.h.gch

在应用gch时,我的方法是:

先使用了include-what-you-use 这个开源工具,去除重复包含的头文件,前置声明替换(也是一种优化)分析路径下头文件的包含频率筛选包含频率高但是改动频率小头文件,放在新的inc.h文件中剔除cpp文件包含的上一步的头文件,并在cpp中首行插入#include "inc.h"修改Makefile,修改依赖关系,编译时先对inc.h进行编译,生成最新的inc.h.gchMakefile 可以加入 -Winvalid-pch,inc.h.gch 不可用时编译报错

工具

从上面第二步开始 ,以我的仓库里的代码举例 ,GchTool/TestTool/dirA.bak 是预编译头优化前, dirA 是优化后 ,大家可以对比参考。

一些脚本说明

分析路径下头文件包含频率:CheckInclude.cpp

使用: ./CheckInclude TestTool/dirA ,

生成 analyseInc.txt , 供 ReplaceGCH.sh 脚本使用:

analyseInc2.txt ,方便我们自己查看头文件包含频率 :

可以根据 git 或者 svn 提交记录,手动从 analyseInc.txt 剔除改动频率大的头文件,(头文件包含应是递归包含的,当时没有考虑到嵌套问题)使用预编译头替换脚本ReplaceGch.sh

使用:./ReplaceGCH.sh TestTool/dirA/ 3 取 analyseInc.txt 前 3 头文件,对 dirA 路径下,将这些头文件从 cpp 文件中删除,新建文件 inc.h 用于包含这些头文件,并且将 #include "inc.h" 插入刚才修改的 cpp 文件的首行

要处理的头文件数量,根据我们的实际项目规模来确定,这里举例是 3

向受到影响的 cpp 文件 插入 inc.h ,会调用InsertInc 脚本:

自动创建 inc.h :

修改 Makefile

修改 dirA/Makefile 依赖,保证每次编译先对 inc.h 进行编译 生成 inc.h.gch

修改 项目Makefile,支持多核编译(目录间多核,比如 dirA 对 inc.h 编译生成 inc.h.gch 时,其他目录仍然在编译):

这里 targetA 是公共库目录 ,targetB、targetC 都要依赖 targetA,如 targetA 生成的静态库

对 inc.h 包含的头文件递归检查,刷新 inc.h 的时间戳,促使生成新的 inc.h.gch (比如inc.h 包含 common.h ,我们对 common.h 修改,gcc 并不认为 inc.h 有改动,因此我编写了脚本 gchcheck.py做编译前检查):

过程输出

进行编译优化后,发现在多核编译中, 目录A产生编译错误时,目录B不会停下来编译,会将错误信息刷屏,我们需要花很多时间向上滚屏翻记录,十分不友好;另外冗余的编译信息(如编译参数 链接参数 都可以在 Makefile 中查看)对我们用处不大。

于是编写脚本,在编译时收集编译信息,友好的展示出来:compliedisplay.py

代码与使用示例

旧的编译信息输出:

修改后:

使用方法:

修改项目 Makefile

红框:调用脚本,我放在了targetA中调用,后台会fork子进程

绿框:ENTRY = ‘$@file’、DIR=$(DIRB)、 2>>$@error 将信息传给编译的子目录,编译信息会写入文件 targetAfile,错误信息写入文件 targetAerror , 对于targetB 则是 targetBfile targetBerror

黄框:表示 target 编译结束

修改子目录下 Makefile ,举例 dirA/Makefile

红框:开始编译文件

绿框:开始链接

注意在这些命令前加上@, 在 $(CXX) xxxx 前也加上,这样就不会打印这条执行语句了。

小结

现在3.16的cmake,可以对预编译头友好支持,无需手动处理预编译头文件中的依赖关系(target_precompile_headers);也可以使用clang替换gcc;在内存足够、核心足够的机器上,预编译头可能是一种负担(如何筛选预编译的文件,标准库头文件)。

关于预编译机制:

第一次编译并保存这个预编译头状态比编译这些代码慢(时间代价20%-200%);

重新加载已保存的状态很快;

足够内存的系统,预编译头文件机制速度比编译单个标准头文件快很多;

根据头文件使用频率和稳定性分层(结论一致);

优化:(不行)

本内容不代表本网观点和政治立场,如有侵犯你的权益请联系我们处理。
网友评论
网友评论仅供其表达个人看法,并不表明网站立场。