MAP 文件分析 - 我的代码大小从何而来？
我正在寻找一种工具来简化分析大型 C++ 项目 (VC6) 的链接器映射文件。
在维护期间，二进制文件稳步增长，我想弄清楚它来自哪里。 我怀疑不同 DLL 之间共享的库中存在一些过度热心的模板扩展，但仅浏览映射文件并不能提供良好的线索。
有什么建议么？
I am looking for a tool to simplify analysing a linker map file for a large C++ project (VC6).
During maintenance, the binaries grow steadily and I want to figure out where it comes from. I suspect some overzealeous template expansion in a library shared between different DLL's, but just browsing the map file doesn't give good clues.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这是一个出色的编译器生成的地图文件分析/浏览器/查看器工具。 检查您是否可以探索 gcc 生成的地图文件。
amap：用于分析 32 位 Visual Studio 编译器生成的 .MAP 文件并报告数据和代码使用的内存量的工具。
此应用程序还可以读取和分析由 Xbox360、Wii 和 PS3 编译器生成的 MAP 文件。
This is a wonderful compiler generated map file analysis/explorer/viewer tool. Check if you can explore gcc generated map file.
amap : A tool to analyze .MAP files produced by 32-bit Visual Studio compiler and report the amount of memory being used by data and code.
This app can also read and analyze MAP files produced by the Xbox360, Wii, and PS3 compilers.
地图文件应该有每个部分的大小，您可以编写一个快速工具来按此大小对符号进行排序。 MSVC (undname.exe) 附带了一个命令行工具，您可以使用它来对符号进行解调。
将符号按大小排序后，您可以根据需要每周或每天生成此符号，并比较每个符号的大小随时间的变化情况。
来自任何单个构建的地图文件可能无法提供太多信息，但编译后的地图文件的历史报告可以告诉您很多信息。
The map file should have the size of each section, you can write a quick tool to sort symbols by this size. There's also a command line tool that comes with MSVC (undname.exe) which you can use to demangle the symbols.
Once you have the symbols sorted by size, you can generate this weekly or daily as you like and compare how the size of each symbol has changed over time.
The map file alone from any single build may not tell much, but a historical report of compiled map files can tell you quite a bit.
您是否尝试过在 .obj 文件上使用 dumpbin.exe？
要寻找的东西：
如果上述任何情况适用于您。 检查它们是否具有广泛的可见性，即它们是否在您的应用程序的大部分中使用/看到。
Have you tried using dumpbin.exe on your .obj files?
Stuff to look for:
If anything of the above applies to you. Check if they have a wide visibility, i.e. if they are used/seen in large parts of your application.
没有对工具的建议，但猜测可能的原因：您是否启用了增量链接？ 这可能会在后续构建期间导致扩展...
如果您使用 /opt:ref 进行编译，链接器将删除未使用的符号，因此，如果您使用它而不使用增量链接，我预计二进制文件的扩展仅是添加实际新代码的结果。 据我所知...希望它能有所帮助。
No suggestion for a tool, but a guess as to a possible cause: do you have incremental linking enabled? This can cause expansion during subsequent builds...
The linker will strip unused symbols if you're compiling with /opt:ref, so if you're using that and not using incremental linking, I would expect expansion of the binaries to be only a result of actual new code being added. That's as far as I know... hope it helps a little.
LinkerScope 是一个用于此特定目的的 python 程序。 它直接从 GNU 的链接器
.map文件生成 SVG 内存映射图，或者您可以指定多个内存区域并执行自定义内存映射。免责声明：我是作者。
LinkerScope is a python program for this specific purpose. It generates SVG memory map diagrams directly from GNU's linker
.mapfiles, or you can specify several memory regions and do your custom memory maps.Disclaimer: i'm the author.
模板、宏、STL 通常都占用大量空间。 BOOST 被誉为一个伟大的通用库，为项目增加了很多空间。 BOOST_FOR_EACH 就是一个例子。 它有数百行模板化代码，可以通过编写适当的循环句柄来避免，通常只需再敲击几个键即可。
使用 Visual AssistX 来节省打字，而不是使用模板。 还要考虑拥有您使用的代码。 宏和内联函数扩展不一定会出现。
另外，如果可以的话，放弃 DLL 体系结构，将所有内容静态链接到一个以不同“模式”运行的可执行文件中。 多次使用相同的可执行映像绝对没有问题，只需根据您想要执行的操作传入不同的命令行参数即可。
DLL 是浪费空间和减慢项目运行时间的罪魁祸首。 人们认为它们可以节省空间，但事实上它们往往会产生相反的效果，有时会使项目大小增加十倍！ 另外，它们增加了交换。 使用固定代码部分（无重定位部分）来提高性能。
Templates, macros, STL in general all use a tremendous amount of space. Heralded as a great universal library, BOOST adds much space to projects. BOOST_FOR_EACH is an example of this. Its hundreds of lines of templated code, which could simply be avoided by writing a proper loop handle, which is in general only a few more key strokes.
Get Visual AssistX to save typing, not using templates. Also consider owning the code you use. Macros and inline function expansion are not necessarily going to show up.
Also, if you can, move away from DLL architecture to statically linking everything into one executable which runs in different "modes". There is absolutely nothing wrong with using the same executable image as many times as you want just passing in a different command line parameter depending on what you want it to do.
DLL's are the worst culprit for wasting space and slowing down the running time of a project. People think they are space savers, when in fact they tend to have the opposite effect, sometimes increasing project size by ten times! Plus they increase swapping. Use fixed code sections (no relocation section) for performance.