MAP 文件分析 - 我的代码大小从何而来？答案

【问题标题】：MAP file analysis - where's my code size comes from?MAP 文件分析 - 我的代码大小从何而来？
【发布时间】：2009-02-23 11:25:58
【问题描述】：

我正在寻找一种工具来简化对大型 C++ 项目 (VC6) 的链接器映射文件的分析。

在维护期间，二进制文件稳定增长，我想弄清楚它的来源。我怀疑在不同 DLL 之间共享的库中存在一些过分热心的模板扩展，但是浏览地图文件并没有提供很好的线索。

有什么建议吗？

【问题讨论】：

【解决方案1】：

This是一款出色的编译器生成地图文件分析/浏览器/查看器工具。检查是否可以浏览 gcc 生成的地图文件。

amap ：一种分析由 32 位 Visual Studio 编译器生成的 .MAP 文件并报告数据和代码使用的内存量的工具。此应用还可以读取和分析由 Xbox360、Wii 和 PS3 编译器生成的 MAP 文件。

【讨论】：

【解决方案2】：

地图文件应该有每个部分的大小，您可以编写一个快速工具来按此大小对符号进行排序。还有一个 MSVC (undname.exe) 附带的命令行工具，您可以使用它来解开符号。

将符号按大小排序后，您可以根据需要每周或每天生成此符号，并比较每个符号的大小随时间的变化情况。

任何单个构建中的地图文件本身可能不会说明太多，但已编译地图文件的历史报告可以告诉您很多。

【讨论】：

【解决方案3】：

您是否尝试过在您的 .obj 文件上使用 dumpbin.exe？

要寻找的东西：

如果上述任何一项适用于您。检查它们是否具有广泛的可见性，即是否在您的应用程序的大部分中使用/看到它们。

【讨论】：

【解决方案4】：

没有对工具的建议，但猜测可能的原因：您是否启用了增量链接？这可能会导致后续构建期间的扩展...

如果您使用 /opt:ref 进行编译，链接器将删除未使用的符号，因此如果您使用它而不使用增量链接，我希望二进制文件的扩展只是实际新代码的结果添加。据我所知...希望对您有所帮助。

【讨论】：

【解决方案5】：

模板、宏、STL 通常都占用大量空间。 BOOST 被誉为一个伟大的通用库，为项目增加了很多空间。 BOOST_FOR_EACH 就是一个例子。它的数百行模板化代码，可以通过编写适当的循环句柄来避免，通常只需多敲几下键。

获取 Visual AssistX 以节省输入，而不是使用模板。还要考虑拥有您使用的代码。宏和内联函数扩展不一定会出现。

此外，如果可以的话，请从 DLL 架构转移到将所有内容静态链接到一个以不同“模式”运行的可执行文件中。使用相同的可执行映像多次使用绝对没有错，只需根据您希望它执行的操作传入不同的命令行参数即可。

DLL 是浪费空间和减慢项目运行时间的罪魁祸首。人们认为他们是节省空间的人，而实际上他们往往会产生相反的效果，有时会将项目规模扩大十倍！另外，它们增加了交换。使用固定代码段（无重定位段）来提高性能。

【讨论】：