C++ 减少编译器生成的tlog文件的大小

由于构建服务器上的构建速度越来越慢，我试图找出原因。似乎它主要挂起在

.tlog

文件的磁盘IO操作中，因为没有CPU负载，构建仍然挂起。即使一个项目只包含10个cpp文件，它也会在

CL.read.1.tlog

文件中生成约5500行。 可疑的是，该文件多次包含相同的头，尤其是占文件90%的boost头

这些文件太大并且有多余的内容，这真的是预期的行为吗？或者可能是源代码引发的问题？是否存在可能导致此问题的循环包含或标题包含过多

更新1 在所有的评论之后，我将尝试在这里澄清更多的细节

我们只是通过包含头并链接已经编译的lib来使用boost，而不是编译boost本身

是的，SSD总是一个很好的改进，但是构建服务器由我们的IT托管，我们没有可用的SSD。（见下文各点）

在编译过程中，我特别通过perfmon检查了一些perfcounters。虽然CPU和内存负载在大多数情况下可以忽略不计，但磁盘IO计数器和队列大小一直都很高。磁盘活动-最高活动时间始终为100&如果我对总时间（B/s）进行排序，则所有tlog文件都已满，这些文件会向磁盘读取/写入大量数据

即使在某些情况下5500行tlog看起来还可以，我还是想知道为什么一次又一次地包含完全相同的boost头文件。一个日志文件，我在其中审查了我们自己的标题

没有病毒影响。我停下来调查，因为我们知道它对我们的汇编影响更大

在我的本地开发人员机器上，使用SSD构建整个解决方案需要约16分钟，而在使用“较慢”磁盘的构建服务器上，则需要约2小时。CPU和内存是可比的。5500行文件只是20-30个项目解决方案中单个项目的一个示例。我们有一个项目，其中有大约30MB的tlog文件，其中有大约60000行，只有这个项目需要一半的编译时间

当然，在编译过程中，机器上有一些基本的CPU负载。但它无法与其他使用SSD的开发人员机器进行比较

我们有45个项目的.net解决方案在12分钟内完成（包括WiX的安装项目）

---

与使用SSD的开发人员机器一样，在CPU/内存配置相当的情况下，我们至少可以将时间从2小时减少到16分钟。我认为瓶颈始终是硬盘。根据permon，检查与磁盘相关的操作会让我找到tlog文件，因为它们导致了最高的磁盘活动

最明显的第一步是确保将它们写入SSD。接下来，如果某个地方的配置错误让您陷入如此深重的困境，那么您可能会遇到配置错误，但我对VS知之甚少。您说它似乎主要挂在.tlog磁盘I/O上。在尝试优化错误的东西之前，最好确保这一点。由于您使用Boost，构建是否可能只需要很长时间，因为大型Boost头文件具有很多依赖项，因此需要从磁盘读取和处理大量头文件？与所有必须读取的头文件相比，.tlog文件中的5500行是微不足道的，即使不使用Boost，而只是使用标准库。您的构建依赖关系树中是否有大量节点？看起来这是由msbuild进程创建的，该进程确定需要构建哪些内容以及何时构建。您是否可以按程序生成数千个头文件，每个头文件都包含boost库或类似的东西？@xaxxon编译器I/O性能基于文件的数量和大小，而不是TUs。如果其中一个包含了boost的一半，那么只有10个tu是无关紧要的。构建10个文件需要多少时间？您正在使用SSD吗？是否安装了防病毒软件？