了解海湾合作委员会'-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`的输出

回答

相关问题