瞭解海灣合作委員會'-fmem-report`的輸出

我應該如何解釋GCC的-fmem-report標誌給出的輸出？瞭解海灣合作委員會'-fmem-report`的輸出

我可以從表格和後續統計中檢索哪些信息？

我試過在編譯期間檢索峯值內存消耗，並直覺地認爲表格的最後一行（Total）爲我提供了值。但是這些與我在top中看到的不一樣。
編譯我的項目時，gcc進程的最高峯值大約爲1.7GB，但在構建日誌中可以找到的最大值大約爲750MB。

其他GCC標誌可以幫助我監控這些〜1.7GB？或者我是否需要將make內部的腳本監控gcc和ld進程？

鑑於以下輸出，什麼值是最重要和最具信息性的？

Memory still allocated at the end of the compilation process 
Size Allocated  Used Overhead 
8    40k   38k  1200 
16   104k  100k  2288 
32   296k  295k  5328 
64   20k   16k  320 
128   4096   384   56 
256   48k   45k  672 
512   188k  187k  2632 
1024   888k  887k   12k 
2048   156k  154k  2184 
4096   188k  188k  2632 
8192   56k   48k  392 
16384   16k   16k   56 
32768   32k   0   56 
65536   64k   0   56 
131072  128k  128k   56 
24   236k  232k  4248 
40   36k   33k  576 
48   12k  8496   192 
56   4096  2016   64 
72   12k  8136   168 
80   4096   480   56 
88   1448k  1429k   19k 
96   12k   10k  168 
112   4096  1568   56 
120   8192  5040   112 
184   16k   14k  224 
160   4096   960   56 
168   36k   35k  504 
152   56k   51k  784 
104   4096   416   56 
352   516k  486k  7224 
136   4096   408   56 
Total  4640k  4424k   63k 

String pool 
entries  16631 
identifiers 16631 (100.00%) 
slots  32768 
deleted  0 
bytes  252k (17592186044415M overhead) 
table size 256k 
coll/search 0.4904 
ins/search 0.0345 
avg. entry 15.55 bytes (+/- 9.75) 
longest entry 66 

??? tree nodes created 

(No per-node statistics) 
Type hash: size 1021, 27 elements, 0.140351 collisions 
DECL_DEBUG_EXPR hash: size 1021, 0 elements, 0.000000 collisions 
DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.000000 collisions 
no search statistics 
decl_specializations: size 61, 0 elements, 0.000000 collisions 
type_specializations: size 61, 0 elements, 0.000000 collisions 
No gimple statistics 

Alias oracle query stats: 
    refs_may_alias_p: 0 disambiguations, 0 queries 
    ref_maybe_used_by_call_p: 0 disambiguations, 0 queries 
    call_may_clobber_ref_p: 0 disambiguations, 0 queries 

PTA query stats: 
    pt_solution_includes: 0 disambiguations, 0 queries 
    pt_solutions_intersect: 0 disambiguations, 0 queries

來源

2012-07-07 Torbjörn

不知道它與'17592186044415M架空'＃ – Dani 2012-07-14 13:38:55

輸出顯示在編譯過程中使用了什麼內存。 GCC/G ++根據需要在各種大小的塊中分配內存。

採取的第一個條目，例如：

Size Allocated  Used Overhead 
8    40k   38k  1200

這表明的存儲器40K在8字節的塊被分配，即40K的，38K是由編譯器使用，並且1200個字節是「會計高架'。 Malloc（3）並不總是完全按照你的要求返回，通常有幾個字節表明這個塊有多大，各種會計數據（誰擁有這個塊），如果事情需要對齊，可能會有未使用的字節。

基本上，這些信息只是會計記錄。

接近最後的散列表的東西顯示了井散列例程的工作方式，以允許GCC/G ++在它的表中查找事物，發生了多少次碰撞（相同的散列值），哪些需要處理等等向前。

我喜歡在「字符串池」中的「字節」條目：

bytes  252k (17592186044415M overhead)

多少內存沒有考慮到存儲字符串？我的天啊！！這就是MEGABytes。 {咧嘴}可能是一個錯誤。可能不是......你有多少ram？

總的來說，GCC/G ++在編譯過程中使用了1.7GB，因爲這是可用的，請考慮，您是否使用了多個/並行編譯？（-j開關），這會增加使用量，因爲並行程序不會相互通信。使用512M內存編譯相同的內存只需要更長的時間，因爲GCC/G ++必須更頻繁地停止和清理以保持足夠的內存。

如果你想看到它在更小的內存限制如何反應，看看在的ulimit命令，尤其是d，v，米也許升限制。請記住使用-S（軟限制）開關，否則您將不得不關閉終端/控制檯/ konsole以重新獲得無限制的限制。（聽起來像是那裏的營銷計劃）

來源

2012-07-10 10:30:25 lornix

感謝您的時間和答案。我有4GB的內存，並沒有做並行編譯，因爲這將導致大約半小時的廣泛交換和無法使用的計算機。是的，這些'17592 ... M'真的很奇怪。我會嘗試與'ulimit'一起玩。謝謝你的提示。 – 2012-07-10 14:14:57

fmem-report是在gcc源代碼中的common.opt文件中定義的。您可以使用ctags和cscope來獲取設置fmem-report標誌的實際文件，然後您需要查看正在檢查此標誌的代碼。如果你沒有得到這個讓我知道我會發現它

來源

2012-07-14 13:34:49 neel

瞭解海灣合作委員會'-fmem-report`的輸出

回答

相關問題