最近遇到联合编译器,编译 C++ 代码突然变得很慢,需要 10 分钟+
于是进行了一番排查,记录一二
查看编译记录,似乎联合编译器不怎么正常了,大多数均在本地打包机上编译 C++ 代码
最开始以为,联合编译器坏掉了,因此重新安装升级了联合编译器,结果还是一样
修改调度算法后,可以确认联合编译器是正常工作的,每个从机都有 C++ 在编译
但是结果还是很慢,没大的变化
于是猜测,是否哪里遇到瓶颈
首先想到的是联合编译器的工作原理:
.o 文件会涉及到写调度器所在主机磁盘以及目标机磁盘
而磁盘读写速率是有限的
于是观察了下,对应主机的磁盘读写、网络上下行速率
但均在两、三分钟恢复空闲
在观察每台从机 cc1plus 进程情况时,发现都很多
但很快都没了,但是会某从机一个 cc1plus 进程会一直 100% 持续 6 、7 分钟
于是看了下该进程的命令行,确定在编译,但是命令行的编译文件,已经被联合编译器重名为 uuid 型文件名了
CMakeLists.txt 加:
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "${CMAKE_COMMAND} -E time")
set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK "${CMAKE_COMMAND} -E time")
可以打印编译、链接时间
于是发现一 CPP 文件需要花费 6 、7 分钟
至此发现了慢的原因
通常性能优化时,经常考虑单点、热点问题
今天在联合编译器使用上,也发现单点问题
其他 CPP 文件很快编译完成,但是卡在 1 个非常慢速的 CPP 文件编译上,导致整体时间被拖垮
之前使用联合编译器,从没认真思考过,想当然认为机器越多编译速度越快
现在总结下,联合编译器,至少耗时,受以下因素影响:
至少需要花费:
MAX(A, B) + C
其中, B C 与文件数量成正比
以上