MAP文件分析——我的代码大小来自哪里？

Question

19

我正在寻找一种工具，可以简化对一个大型C++项目（VC6）的链接器映射文件进行分析。在维护过程中，二进制文件不断增长，我想弄清楚它是从哪里来的。我怀疑某个库中有一些过度使用模板导致了这种情况，但仅仅浏览映射文件并没有给出很好的线索。您有什么建议吗？

- peterchen

5个回答

2

你尝试过在.obj文件上使用dumpbin.exe吗？

需要查找的内容：

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

- ralphtheninja

2

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

一旦您按大小对符号进行了排序，您可以按周或按日生成此内容，并比较每个符号的大小随时间的变化情况。

任何单个构建的地图文件可能并不能告诉太多信息，但是编译的地图文件的历史报告可以告诉您很多东西。

- Dan Olson

1

没有关于工具的建议，但是有一个可能的原因：你启用了增量链接吗？这可能会导致在后续构建过程中出现扩展...

如果你正在使用/opt:ref进行编译并且不使用增量链接，链接器将会剥离未使用的符号，因此我预计二进制文件的扩展仅取决于实际添加的新代码。就我所知，就这些了...希望能有所帮助。

- Nick

/opt：ref 已启用，发布版本构建已禁用增量链接（受影响）。但是，那些是要检查的第一件事。 - peterchen

0

模板、宏、STL通常会占用大量空间。BOOST被誉为伟大的通用库，但它也会给项目增加很多空间。BOOST_FOR_EACH就是一个例子。它有数百行的模板代码，而这些代码可以通过编写适当的循环处理来避免，一般只需要多按几个键。

使用Visual AssistX可以节省打字时间，不必使用模板。此外，考虑拥有您使用的代码。宏和内联函数扩展并不一定会出现。

如果可能的话，将DLL架构移动到静态链接所有内容的可执行文件中，该文件在不同的“模式”下运行。完全没有问题使用相同的可执行映像，只需根据所需的操作传入不同的命令行参数即可。

DLL是浪费空间和减慢项目运行时间的最糟糕的罪魁祸首。人们认为它们可以节省空间，但实际上它们往往产生相反的效果，有时会使项目大小增加十倍！此外，它们还会增加交换。使用固定的代码段（无重定位段）以提高性能。

- Jordan

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- prashant · Accepted Answer

这个是一个非常好用的编译器生成的地图文件分析/浏览/查看工具。可以检查是否能够浏览由gcc生成的地图文件。

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