1

我应该如何解释 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
4

2 回答 2

4

输出显示编译期间使用的内存。GCC/G++ 根据需要以各种大小的块分配内存。

以第一个条目为例：

Size   Allocated        Used    Overhead
8             40k         38k       1200

这表明 40K 的内存以 8 字节块的形式分配，其中 40K，38K 被编译器使用，1200 字节是“会计开销”。Malloc(3) 并不总是准确地返回你所要求的，通常有几个字节表示这个块有多大，各种会计数据（谁拥有这个块），如果需要对齐，可能会有也未使用的字节。

基本上，这些信息只是会计记录。

接近结尾的哈希表显示了哈希例程是如何工作的，以允许 GCC/G++ 在其表中查找内容、发生了多少冲突（相同的哈希值）、需要处理的内容等等。

我确实喜欢“字符串池”中的“字节”条目：

bytes       252k (17592186044415M overhead)

存储字符串需要多少内存？我的天啊！！那就是兆字节。{Grin} 可能是个错误。可能不会...你有多少内存？

总的来说，GCC/G++ 在你的编译过程中使用了 1.7GB，因为那是可用的，同时考虑一下，你是否使用了多重/并行编译？（-j 开关），这将增加使用量，因为并行程序不相互交谈。用 512M 的可用 RAM 编译同样需要更长的时间，因为 GCC/G++ 必须更频繁地停止和清理以保持足够的可用 RAM。

如果您想了解它在较小的内存限制下如何反应，请查看ulimit命令，尤其是d、v、m和l限制。请记住也使用-S（软限制）开关，否则您必须关闭终端/控制台/控制台才能重新获得无限限制。（听起来像是那里的营销计划）

于 2012-07-10T10:30:25.473 回答
0

fmem-report 在 gcc 源代码的 common.opt 文件中定义。您可以使用 ctags 和 cscope 来获取设置 fmem-report 标志的实际文件，然后您需要查看检查此标志的代码。如果你不明白，让我知道我会找到的

于 2012-07-14T13:34:49.920 回答