MAP文件分析 - 我的代碼大小從哪裏來？

我找簡化分析鏈接器映射文件的大型C++項目（VC6）的工具。MAP文件分析 - 我的代碼大小從哪裏來？

在維護期間，二進制文件穩步增長，我想弄清楚它來自哪裏。我懷疑在不同的DLL之間共享的庫中存在一些過分的模板擴展，但是對於地圖文件的修剪並不能提供很好的線索。

有什麼建議嗎？

來源

2009-02-23 peterchen

This是一個美妙的編譯器生成的地圖文件分析/資源管理器/查看器工具。檢查你是否可以探索gcc生成的地圖文件。

AMAP：一個工具來分析.MAP由32位的Visual Studio編譯器產生的文件和報告正在使用的數據和代碼的存儲器的量。此應用還可以讀取和分析Xbox360，Wii和PS3編譯器生成的MAP文件。

來源

2012-09-19 11:09:32 prashant

感謝您的回覆 - mroe或更少我正在尋找:) – peterchen 2012-09-19 13:43:44

對工具沒有建議，但對可能的原因有一個猜測：您是否啓用了增量鏈接？這可能會導致擴大在隨後的建立......如果你通過/ opt編譯

連接器將未使用的剝離符號：裁判，所以如果你使用和不使用增量鏈接，我希望擴大二進制文件只是添加實際新代碼的結果。據我所知...希望它有一點幫助。

來源

2009-02-23 18:33:03 Nick

/opt：ref已啓用，對於發佈版本（受影響）禁用增量鏈接。但是，是的，這是第一件事要檢查 – peterchen 2009-02-23 21:37:19

地圖文件應該有每個部分的大小，你可以寫一個快速的工具來按這個大小對符號進行排序。還有一個命令行工具附帶MSVC（undname.exe），您可以使用它來對符號進行分解。

一旦你按大小排序的符號，你可以生成這個每週或每天，你喜歡和比較各符號的大小隨着時間的推移發生變化。

從任何一個單獨構建的地圖文件可能不告訴不多，但已編譯的映射文件的歷史報表可以告訴你不少。

來源

2009-02-23 18:42:40

您是否嘗試過使用DUMPBIN.EXE在你的obj文件？

東西去尋找：

使用了很多STL的？
很多類的C++內聯的方法呢？
很多常量？

如果上述任何適用於您。檢查它們是否具有廣泛的可見性，即它們是否在應用程序的大部分中使用/看到。

來源

2009-06-14 01:00:10 ralphtheninja

-1

模板，宏，STL一般都使用的空間了大量。作爲一個偉大的通用圖書館，BOOST爲項目增加了很多空間。 BOOST_FOR_EACH就是一個例子。它有數百行模板化代碼，通過編寫適當的循環句柄可以簡單地避免這種情況，通常只需要幾個按鍵。

獲取視覺AssistX節省打字，不使用模板。還要考慮擁有你使用的代碼。宏和內聯函數擴展不一定會顯示出來。另外，如果可以的話，從DLL體系結構移到靜態鏈接到一個可執行文件，該文件運行在不同的「模式」中。使用相同的可執行映像的次數絕對沒有問題，只需要傳入不同的命令行參數即可，具體取決於您希望執行的操作。

DLL是浪費空間和減慢項目運行時間的最大罪魁禍首。人們認爲他們是節約空間的人，事實上他們往往會產生相反的效果，有時會把項目規模增加十倍！另外他們增加交換。使用固定的代碼部分（無重定位部分）獲得性能。

來源

2010-12-16 13:19:25 Jordan

MAP文件分析 - 我的代碼大小從哪裏來？

回答

相關問題