当前位置：文江博客话题详情

我的 C++ 目标文件太大

发布于 2024-07-13 01:10:14 字数 102 浏览 9 评论 0原文

我正在开发一个 C++ 程序，来自单个 1200 行文件（初始化一个相当复杂的状态机）的编译目标代码接近一兆字节。是什么原因导致文件如此之大？有没有办法找到目标文件中占用空间的内容？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

不打扰别人 2024-07-20 01:10:15

（我假设您已经打开了优化和死代码剥离）。

打开链接器的“生成映射文件”选项并检查输出。

常见的罪魁祸首是产生大量代码和大型全局对象的宏/模板。

回复收藏 0 原文

扶醉桌前 2024-07-20 01:10:15

可能是一些模板实例化（尤其是 std::iostream），也可能是广泛的内联（即在标头中完全定义的类）。然而，1MB 的目标文件首先有什么问题呢？在链接过程中，很可能会产生一个很小的二进制文件。我在这里有一个项目，其中包含 20 MiB 的目标文件，例如链接到 700 KiB 的二进制文件。

更新：也可能是一些大型静态数组/对象。除此之外，使用 MSVC++ 和 GCC，您可以查看文件生成的程序集，这可以给您一些提示（对于 GCC，它是 g++ -S foo.cpp，对于 MSVC++，它是 '/FAs'）。要么您会看到很多模板实例，那么这就是原因。如果不是，则它是静态对象的对象大小。

回复收藏 0 原文

红颜悴 2024-07-20 01:10:15

另一个可能的原因是链接时代码生成，这是一个 VC++ 选项。这会将编译器的后端移至链接器中。这可以实现更好的优化，但目标文件现在必须包含通常在前端和后端之间传递的所有内部数据结构。

回复收藏 0 原文

满地尘埃落定 2024-07-20 01:10:15

一个不错的选择是看看分析 ELF 部分和符号大小的工具例如：

nm -C --print-size --size-sort --radix=d tst.o
size -A -d tst.o | sort -k2 -n

我见过 C++ 中调试符号很大的情况，例如比二进制文件的其余部分大 30 倍，所以这绝对是需要注意的事情之一，上面的 size 命令会立即提示您由于与调试相关的部分巨大，您可以通过使用 strip 或 g++ -s 剥离二进制文件来进行双重检查。

另一件需要注意的事情是，您是否可以通过显式模板实例化来节省一些空间/时间：显式模板实例化 - 何时使用？该答案的“如何快速分析您的构建以查看它是否会从模板实例化中获益”部分还包含一种查找重复项的方法大型 (C++) 项目中跨对象文件的对象。

One good bet would also be to have a look at the possibilities mentioned at Tool to analyze size of ELF sections and symbol e.g.:

nm -C --print-size --size-sort --radix=d tst.o
size -A -d tst.o | sort -k2 -n

I've seen cases where debug symbols are MASSIVE in C++, e.g. 30x larger than the rest of the binary, so this is definitely one of the things to look out for, the above size command would tip you off immediately due to huge debug related sections, and you can double check by stripping the binary with strip or g++ -s.

Another thing to look out for is if you can save some space/time with explicit template instantiation: Explicit template instantiation - when is it used? The "How to quickly analyze your build to see if it would gain a lot from template instantiation" section of that answer also contains a methodology to find duplicate objects across object files in a large (C++) project.

回复收藏 0 原文

守护在此方 2024-07-20 01:10:15

您可以通过添加编译标志 -flto -Wl,-allow-multiple-definition 并且可以添加 -fuse-linker-plugin。 -Wa,-mbig-obj 不适用于 x86/32 位架构（仅限 x64）

回复收藏 0 原文

感受沵的脚步 2024-07-20 01:10:15

这是我用来查看编译时值的宏：

template <size_t N> struct compile_time_number { private: typedef int check; };
#define compiler_check_number(N) ((compile_time_number< N >::check)0)

然后在编译时高兴地查看哪些符号占用了空间。

编辑：由于似乎没有人理解这一点，我将澄清：使用它的方法是添加compiler_check_number(sizeof(<在此处插入结构或全局变量>))。编译器会将变量或结构的大小作为编译时错误吐出。代码很少是造成巨大目标文件的原因。

我一直使用它来查看事物有多大，而无需运行调试器。

Here's a macro I use to see compile time values:

template <size_t N> struct compile_time_number { private: typedef int check; };
#define compiler_check_number(N) ((compile_time_number< N >::check)0)

Then go happy at compile time to see what symbols are taking up space.

Edit: Since no one seems to understand this, I'll clarify: the way to use this is to add compiler_check_number(sizeof(<insert struct or global variable here>)). The compiler will spit out the size of the variable or struct as a compile time error. Very rarely is code the reason for a huge object file.

I use this all the time to see how big things are without having to run a debugger.

回复收藏 0 原文