Coverity静态分析变慢，通常不是单一命令的问题，而是捕获、翻译、分析和提交这几段链路里，有一段把资源吃满了。官方文档把增量分析、并行分析和并行翻译单独列成性能优化主题，而且明确说明增量分析是通过在同一代码基上复用同一个中间目录来减少重复工作；并行分析则通过`cov-analyze--jobs`这类方式提高吞吐。

　　一、Coverity静态分析很慢怎么办

　　这一部分先解决“慢在哪里”。更稳的做法，不是上来就一味加机器或加线程，而是先把慢点定位到捕获、翻译还是分析阶段，再做针对性调整。因为Coverity的`cov-build`负责捕获与翻译链路，`cov-analyze`负责检查器分析，两段瓶颈的处理方式并不一样。

　　1、先把慢点分到捕获段还是分析段

　　先分别记录`cov-build`和`cov-analyze`的耗时，不要只看整条流水线总时长。如果`cov-build`慢，优先检查编译捕获和翻译配置；如果`cov-analyze`慢，再去调分析并发和检查器策略。

　　2、先清理无效输入，别让Coverity扫不该扫的代码

　　第三方库、生成代码、历史归档目录、测试样例目录如果本来就不在治理范围内，先从构建输入里剔掉。分析对象一旦缩小，捕获和分析都会直接变快，通常比单纯加线程更有效。

　　3、先核编译器配置是否正确

　　官方说明`cov-configure`会按编译器生成配置，编译器识别不准时，捕获阶段容易出现额外开销或无效翻译。发现同一套代码在不同机上分析速度差异很大时，先回头查编译器配置，而不是先怀疑硬件。

　　4、让中间目录放在本地高速盘

　　中间目录本身会保存emit和分析结果，若放在网络盘或低速盘，I/O会明显拖慢整条链路。尤其是大项目，多文件捕获和分析结果读写对磁盘速度非常敏感。

　　5、把一次大分析拆成更小的构建单元

　　如果项目本身就按模块构建，优先让Coverity也按模块捕获，再汇总到统一流程里。这样做的好处，是便于并行和定位瓶颈，也减少一次性处理中间目录过大的问题。

　　6、先做一轮基线测速再调策略

　　建议固定一份代码版本，分别记录单线程、当前线程数和优化后配置的耗时。没有基线数据时，很难判断是并发真的生效了，还是只是某次构建输入碰巧变少了。

　　二、Coverity并发与增量策略怎么调

　　这一部分解决“怎么让快的机制真正生效”。官方文档对增量分析和并行翻译讲得很清楚，增量分析要求在同一代码基上复用同一个中间目录；并行翻译则是让`cov-translate`或`cov-emit`在单次原生编译调用里并行处理多个文件；并行分析则主要通过`cov-analyze--jobs`来调工作线程数。

　　1、增量分析先保证复用同一个中间目录

　　官方说明里写得很明确，后续`cov-build`要继续使用同一个intermediate directory，然后在这个同一目录上再跑`cov-analyze`，这样才能让增量分析真正减少重复工作；如果你每次都新建idir，增量策略基本等于没开。

　　2、增量策略只适合持续变化的小步提交

　　如果一次改动跨很多模块、头文件改动范围很大，增量分析的收益会下降，因为它仍要重新处理受影响链路。更稳的做法是日常提交走增量，里程碑或大分支合并后补一次全量分析。

　　3、分析并发优先从保守值开始

　　`cov-analyze`支持`--jobs`或`-j`并发，官方文档也明确把它作为并行分析调优入口。实际使用时不要直接把线程数拉到机器逻辑核数上限，先从较保守的值试起，再观察CPU、内存和I/O是否同时顶满。

　　4、翻译并发只在单次编译包含多文件时更有价值

　　官方对parallel translate的描述是，当一次原生编译调用里看到多个文件时，可以并行跑多个`cov-emit`进程。也就是说，如果你的构建本身就是一文件一调用，这项收益会有限；如果编译命令本来就批量带多个源文件，并行翻译才更明显。

　　5、并发不是越大越快，要看资源瓶颈在哪

　　如果机器CPU没满但磁盘打满，提高`--jobs`帮助不大；如果内存已经接近吃光，再加分析线程反而可能触发交换导致更慢。调并发时一定要同时看CPU、内存和磁盘，而不是只看线程数字。

　　6、把增量和并发分开做实验

　　先只开增量看收益，再只调并发看收益，最后再叠加。这样才能判断到底是增量目录复用带来的提升，还是`cov-analyze--jobs`和parallel translate带来的提升，后续才好固化成团队标准配置。

　　三、Coverity分析基线怎么定

　　这一部分解决“以后怎么不反复踩坑”。性能调优如果没有固定基线，下次换编译器、换流水线或换代码规模后，大家又会重新争论到底该不该开增量、线程数该设多少。把基线定下来，比单次把速度调快更重要。([Black Duck文档中心][7])

　　1、固定一套标准代码样本

　　选一份规模稳定、依赖完整、能代表日常项目复杂度的代码版本作为测速样本，后续所有Coverity性能调整都先在这份样本上验证。

　　2、把中间目录策略写进流水线规范

　　明确哪些任务复用同一个idir做增量，哪些任务必须新建idir做全量。规则一旦写清，团队就不会因为每个人各自写脚本而把增量策略做失效。

　　3、把线程口径和机器规格绑定

　　不要只写“开8线程”这种结论，要写清是在多少核、多少内存、什么磁盘环境下得出的。这样换机器时才知道是否需要重新标定`--jobs`。

　　4、按模块记录耗时和输入规模

　　每次分析时记录代码行数、文件数、capture耗时、analyze耗时和提交耗时。后面看到某一轮突然变慢时，可以先判断是代码规模变了，还是策略真的失效了。

　　5、保留一条全量回归线

　　即使日常走增量，也要周期性保留一条全量分析基线。这样既能校验增量目录是否健康，也能避免长期只跑增量后对分析覆盖范围产生误判。

　　总结

　　Coverity静态分析很慢，先别急着加机器，先把瓶颈拆到`cov-build`和`cov-analyze`两段去看，再分别处理输入规模、编译器配置和I/O问题。调并发与增量时，增量分析要保证同一代码基复用同一个中间目录，并行分析靠`cov-analyze--jobs`，并行翻译则更依赖构建命令本身是否一次处理多个文件。最后把Coverity分析基线固定成样本、idir规则和线程口径三件事，后面的性能优化才会真正稳定下来。