很多团队一碰到C/C++test变慢，第一反应就是把线程数往上拧，结果机器风扇转得更猛，出结果却没快多少。原因通常不只一个。Parasoft官方文档里其实把边界写得很清楚，C/C++test的并发线程并不是单看CPU核数，实际还会受可用内存和许可证限制；命令行模式也分不同授权，Desktop Command Line Mode对单个任务的并行线程上限就是8个。换句话说，这类性能问题很多时候不是工具本身“慢”，而是把全量扫描、重建、公共头文件变更和不合适的并发策略混在了一起。

　　一、C/C++test静态分析很慢

　　真要排查，别一上来就改线程。先把时间花在哪一步分开看，思路会清楚很多。

　　1、先分清到底慢在重建还是慢在分析

　　官方命令行文档说明，cpptestcli可以针对解决方案、项目甚至单个资源运行，而且如果工程已经完成构建，可以用-nobuild避免测试前再次重建。项目里最常见的误判，就是每次扫描都顺手把整套构建又跑了一遍，最后把构建时间也算到静态分析头上。

　　2、并发开太猛反而会把机器拖慢

　　Parasoft在并发配置里写得很直白，实际并行线程数要同时看CPU、可用内存和许可证，手动模式下还能单独限制最大线程数，并保留一部分空闲内存给其他进程。也就是说，机器如果本来就在编译、链接、跑容器，你再把线程拉满，结果往往不是提速，而是内存顶满后整体变慢。

　　3、公共头文件改动往往比单个源码文件更伤时间

　　官方说明提到，头文件不是被单独直接分析的，而是通过被测源文件间接纳入分析范围。如果你改的是公共头文件、宏定义或者编译选项，表面上只是动了一个文件，实际上可能连着带出一大片依赖，这种时候扫描耗时突然上来很正常。

　　4、共享文件和自动生成代码别混着扫

　　Parasoft还专门提醒过，多个项目如果共享同一个文件，最好拆开分别跑，避免结果不一致。另一个常见拖慢点，是把自动生成代码、第三方库镜像和长期不维护的目录一起扫进去。官方命令行文档支持排除特定项目资源，这一步做干净，通常比盲目加机器更见效。

　　二、C/C++test并发与增量策略怎么选

　　这部分最怕一刀切。并发解决的是一轮扫描怎么跑，增量解决的是这轮到底扫多大，两者不是一个层面的问题。

　　1、日常提交和本地自测优先选增量思路

　　官方的源代码管理支持说明写明，C/C++test可以利用源代码管理中的修订数据来限制测试范围，限制维度包括作者和修改时间。对开发日常自测、提交前校验和合并请求门禁来说，这就是最实用的增量入口，先把范围收窄，再谈并发，反馈时间通常会更稳。

　　2、改的是普通实现文件可以用中等并发配合小范围扫描

　　如果这次主要动的是局部cpp文件，依赖面不大，那就没必要每次都拉全量。官方命令行支持按资源执行分析，配合源代码管理的范围限制，做成按项目、目录或文件粒度的扫描更合适。这里的经验通常是先用Auto，让工具自己控制，再视机器负载改到Manual。

　　3、改的是公共头文件编译配置或规则集就别硬做窄增量

　　这一点官方没有给出一句“必须全量”的硬规则，但从头文件间接分析、共享文件需分开运行这些机制可以推出来，凡是会放大影响面的改动，都不适合只扫眼前几个文件。尤其是公共头文件、编译器配置、预处理宏和规则配置变了以后，继续用很窄的增量，容易把问题漏到后面。这个判断是基于官方分析机制做出的工程化推断。

　　4、夜间构建和里程碑检查更适合全量加较高并发

　　官方文档区分了Extended Command Line Mode和Desktop Command Line Mode，其中后者单任务并行上限是8线程。如果你们做的是夜间全量扫描、版本候选检查或合规留档，就更应该把这类任务放到专门的构建机上跑，授权允许的话再提高并发；如果团队不想把分析绑在IDE上，Parasoft也提供了可脱离IDE做静态分析的C/C++test DTP Engine。

　　三、C/C++test该先调并发还是先收范围

　　项目里真正能落地的，通常不是“二选一”，而是谁先动手更划算。

　　1、开发反馈已经拖到十几二十分钟先收范围

　　如果构建机并不空闲，或者每次只是改了少量业务代码，那先把扫描从全量改成按改动范围跑，收益通常最大。Parasoft提供的SCM范围控制和DTP变更视图，本来就是为这种场景准备的。

　　2、范围已经够小但机器利用率明显偏低再调并发

　　如果你已经把扫描压到项目级甚至文件级，结果CPU还很闲、内存也充足，那再去调parallel.max_threads才有意义。否则前面范围没收，后面只加线程，通常只是把拥塞放大。这个结论对应的是官方并发配置里对CPU、内存和许可证三者联动的说明。

　　3、最稳的落地方式其实是两套策略并存

　　一套给开发日常提交，用小范围增量扫描，目标是尽快回结果。另一套给夜间构建和发版前检查，用全量扫描兜底，再把结果发到DTP里看构建间变化。这样做不是花哨，而是更贴近官方提供的资源级执行、SCM范围限制和DTP变更比对能力。

　　总结

　　C/C++test静态分析很慢，C/C++test并发与增量策略怎么选，关键不是把线程数拉到多高，而是先判断这次到底该不该扫那么大。日常开发阶段，先把范围收小，保证反馈快；夜间和里程碑阶段，再把全量扫描跑完整，保证结果稳。把这两条线分开以后，C/C++test的性能问题通常就不会再显得那么拧巴，团队也更容易把速度和覆盖面同时顾住。