我应该如何解释GCC -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
答案 0 :(得分:4)
输出显示编译期间使用的内存。 GCC / G ++根据需要以各种大小的块分配内存。
取第一个条目,例如:
Size Allocated Used Overhead
8 40k 38k 1200
这表明40K的内存分配在8字节的块中,其中40K,38K由编译器使用,1200字节是“计费开销”。 Malloc(3)并不总是完全按照你的要求返回,通常有一小部分字节表示这个块有多大,各种会计数据(谁拥有这个块),如果事情需要对齐,可能会有也是未使用的字节。
基本上,这些信息只是会计记录。
接近结尾的哈希表显示井哈希例程如何工作,允许GCC / G ++在其表中查找事物,发生了多少冲突(相同的哈希值),需要处理,等等
我喜欢'String Pool'中的'bytes'条目:
bytes 252k (17592186044415M overhead)
存储字符串需要多少内存?我的天啊!!这就是MEGABytes。 {Grin}可能是一个bug。可能不是......你有多少公羊?
总的来说,GCC / G ++在你的编译过程中使用了1.7GB因为这是可用的,考虑到你是否使用多个/并行编译? (-j switch),这会增加用法,因为并行程序不会相互通信。使用512M可用RAM进行编译只需要更长时间,因为GCC / G ++必须更频繁地停止和清理,以保持足够的RAM可用。
如果您想了解它在较小内存限制下的反应,请查看 ulimit 命令,尤其是 d , v , m 以及 l 限制。请记住也要使用 -S (软限制)开关,否则您必须关闭终端/控制台/ konsole以重新获得无限制的限制。 (听起来像营销计划)
答案 1 :(得分:0)
fmem-report在gcc源代码的common.opt文件中定义。您可以使用ctags和cscope来获取设置fmem-report标志的实际文件,然后您需要查看检查此标志的代码。如果你没有得到这个让我知道我会找到它