CI编译速度优化

Date: 2020/3/6

背景：

并行编译的可靠性不高？编译经常卡住，eGateway无版本可用，影响项目进度。

CI的基本流程

目前eGateway，中央站，Benelink，Jekins的基本工作流如上图所示。

eGateway的编译速度慢在哪里？

1. 工程编译串行化：一个工程编译完了才能编译另外一个工程
2. 文件签名速度慢：文件签名的速度慢。
3. NSIS打包串行化：生成eGatewaySetup.exe, eGatewaySteup_PDB.exe
4. 7z打包压缩串行化：打包完成会生成多个压缩包串行，且较慢

    

   问题：

5. 并行编译的可靠性不高？

   主要表现是卡住不动。

    

    

工程编译串行化：

这个编译，对CPU的有效利用率并不高，比较多的时间花在了编译准备和文件交换上了。

优化策略：

1. 梳理依赖关系，对于没有依赖关系的工程同时编译。提升CPU占用率。
2. 移除Incredibuild软件，这个软件经常导致编译卡死。

经过优化后，节省20分钟左右

文件签名速度慢

文件签名对网络的访问主要是时间戳

目前的网络连接方式，如下图：

对于网络的交互流程，使用的签名工具，都是没有问题，很验证从这个地方进行优化。

优化策略：

1. 一次签一个文件和一次签多个文件时间差不多，目前是一次签多个文件的方式。
2. 减少重复签名。同一二进制文件，多次签名。经过优化后，减少了300个左右签名文件，减少10分钟左右

NSIS打包串行化

NSIS打包生成eGatewaySetup.exe, eGatewaySteup_PDB.exe

经过分析发生，NSIS脚本编译采用单线程的方式，这两个打包是串行方式。

打包使用的压缩压缩算法为LZMA。这个算法暂不支持多线程。

优化策略：

1. 对打化进行并行，同时启动这两个打包。
2. 此步优化后约节省6分钟

    

7z打包压缩串行化

7z 最初的版本为4.65，使用LZMA压缩算法，对多线程支持不好。

优化策略：

使用7z 16.04，支持LZMA2压缩算法，对多线程支持好。提高压缩速度。

eGateway优化对比：

目前优化后的版本还在试用行中，经过初步比对，减少了1个小时左右。

后续的优化策略：

策略：

1. 打印各个工程的时间，看看哪些工程最费时间，进行优化。
2. 查看关键路径，梳理依赖关系，进行优化。

    

关键路径及优化：

1. 多后端的编译很费时间，约35分钟
2. Common目录下工程间的依赖关系不明确，串行编译。优化后预计可以节省5分钟左右。
3. NSIS打包速度过慢，这一步目前耗时10分钟

    

   优化的地方比较多。但考虑好易维护和时间成本。已基本达到预期，暂停止优化。

    

    

Benelink的编译速度慢在哪里？

Benelink不适合使用Incredibuild。或者说对Incredibuild的使用方式不正确。

优化策略：

移除Incredibuild

Incredibuild的使用

适用于哪些场景：

1, 单个工程，拥有大量文件的场景。

2, 如果有多个工程时，需要使用sln，并把多个工程依赖组织好，然后再来编译。

目前我们Common工程的依赖关系组织不明确。而且没有sln的方案，没有发挥出并行编译的优势了性能。

不适用哪些场景：

数量多的小工程（文件数量少）的串行化编译

Benelink优化对比：

经过初步比对，减少了1个小时10分钟左右。

标签：10,CI,工程,编译,串行化,优化,打包
来源： https://www.cnblogs.com/iamkun2005/p/14137306.html