Header文件包含static分析工具？

Question

一位同事最近向我透露，我们的一个源文件在编译期间包含超过 3,400 个头文件。 我们在构建中编译了 1,000 多个翻译单元，这导致肯定不会全部使用的标头导致巨大的性能损失。

是否有任何 static 分析工具能够揭示这样一个森林中的树木，特别是让我们能够决定我们应该处理哪些树木？

更新

在这里找到了一些关于包含 header 文件（以及用于优化其包含的包含防护的类型）成本的有趣信息，源自这个问题。

Answer 1

gcc -w -H <file> 的gcc -w -H <file>可能有用（如果你解析它并输入一些计数） -w可以抑制所有警告，这可能很难处理。

来自 gcc 文档：

-H

打印使用的每个 header 文件的名称，以及其他正常活动。 每个名称都缩进以显示它在#include堆栈中的深度。 预编译的 header 文件也会被打印，即使被发现无效； 一个无效的预编译 header 文件用...x打印，一个有效的用...! .

output 看起来像这样：

. /usr/include/unistd.h
.. /usr/include/features.h
... /usr/include/bits/predefs.h
... /usr/include/sys/cdefs.h
.... /usr/include/bits/wordsize.h
... /usr/include/gnu/stubs.h
.... /usr/include/bits/wordsize.h
.... /usr/include/gnu/stubs-64.h
.. /usr/include/bits/posix_opt.h
.. /usr/include/bits/environments.h
... /usr/include/bits/wordsize.h
.. /usr/include/bits/types.h
... /usr/include/bits/wordsize.h
... /usr/include/bits/typesizes.h
.. /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include/stddef.h
.. /usr/include/bits/confname.h
.. /usr/include/getopt.h
. /usr/include/stdio.h
.. /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include/stddef.h
.. /usr/include/libio.h
... /usr/include/_G_config.h
.... /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include/stddef.h
.... /usr/include/wchar.h
... /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include/stdarg.h
.. /usr/include/bits/stdio_lim.h
.. /usr/include/bits/sys_errlist.h
Multiple include guards may be useful for:
/usr/include/bits/confname.h
/usr/include/bits/environments.h
/usr/include/bits/predefs.h
/usr/include/bits/stdio_lim.h
/usr/include/bits/sys_errlist.h
/usr/include/bits/typesizes.h
/usr/include/gnu/stubs-64.h
/usr/include/gnu/stubs.h
/usr/include/wchar.h

Answer 2

如果您使用 gcc/g++，- -M或-MM选项将 output 与您寻找的信息一行。 （前者将包括系统标头，而后者则不包括。还有其他变体；请参阅手册。）

$ gcc -M -c foo.c
foo.o: foo.c /usr/include/stdint.h /usr/include/features.h \
  /usr/include/sys/cdefs.h /usr/include/bits/wordsize.h \
  /usr/include/gnu/stubs.h /usr/include/gnu/stubs-64.h \
  /usr/include/bits/wchar.h

您需要删除开头的foo.o: foo.c ，但 rest 是文件所依赖的所有头文件的列表，因此编写脚本来收集和总结它们并不难。

当然，这个建议只对 Unix 有用，并且只有在没有其他人有更好的想法的情况下才有用。 :-)

Answer 3

一些东西-

• 使用“仅预处理”查看您的预处理器 output。 gcc -E 选项，其他编译器也有 function

• 使用预编译的头文件。

• gcc 具有 -verbose 和 --trace 选项，它们也显示完整的包含树，MSVC 具有在高级 C++ 属性页下找到的 /showIncludes 选项

此外， 在 Visual Studio 中显示 C++ 文件的#include 层次结构

Answer 4

GCC 有一个-M标志，它将 output 给定源文件的依赖项列表。 您可以使用该信息来确定哪些文件具有最多的依赖关系，哪些文件最依赖，等等。

查看手册页以获取更多信息。 -M有几种变体。

Answer 5

John Lakos 的“大型 C++ 软件设计”具有提取源文件之间编译时依赖关系的工具。

不幸的是，他们在 Addison-Wesley 网站上的存储库已经消失（连同 AW 的网站本身），但我在这里找到了一个 tarball： http://prdownloads.sourceforge.net/introspector/LSC-rpkg-0.1.tgz?download

我在几个工作前发现它很有用，而且它具有免费的优点。

顺便说一句，如果你还没有读过 Lakos 的书，听起来你的项目会受益。 （目前的版本有点过时，但我听说 Lakos 在 2012 年还有另一本书出版。）

Answer 6

就我个人而言，我不知道是否有一个工具会说“删除这个文件”。 这确实是一个复杂的问题，取决于很多事情。 看着一棵包含语句的树肯定会让你发疯......它会让我发疯，也会毁了我的眼睛。 有更好的方法来减少编译时间。

1. 取消内联您的 class 方法。
2. 在将它们内联后，重新检查您的包含语句并尝试删除它们。 通常有助于删除它们，然后重新开始。
3. 尽量使用前向声明。 如果您在 header 文件中取消内联方法，则可以执行很多操作。
4. 将大 header 文件分解为较小的文件。 如果文件中的 class 的使用频率高于大多数，则将其单独放入 header 文件中。
5. 1000 个翻译单位其实并不多。 我们有10-20千。 :)
6. 如果您的编译时间仍然太长，请获取 Incredibuild。

Answer 7

我听说有一些工具可以做到这一点，但我不使用它们。

我创建了一些工具https://sourceforge.net/p/headerfinder可能有用。 不幸的是，它是“自制”工具，存在以下问题，

• 在 Vb.Net 中开发
• 源代码需要编译
• 非常慢并且消耗 memory。
• 没有可用的帮助。

Answer 8

GCC 有一个标志（-save-temps），您可以使用它保存中间文件。 这包括 .ii 文件，它们是预处理器的结果（所以在编译之前）。 您可以编写一个脚本来解析它并确定所包含内容的权重/成本/大小，以及依赖关系树。

我写了一个 Python 脚本来做到这一点（在这里公开可用： https://gitlab.com/p_b_omta/gcc-include-analyzer ）。