> The patch is about usage of MiB in memory allocation reports.
> I see it much better readable than values displayed in KiB:
>
> Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB}
> {GC 19 MiB} {heap 12 MiB}
> Reading the symbol table:
> Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB ->
> 27 MiB} {GC 27 MiB} {heap 15 MiB}
> Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27
> MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap
> 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15
> MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB}
> Merging symbols: {heap 15 MiB}Materializing decls:
> <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap
> 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra>
> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap
> 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB
> madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB}
> <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB}
> Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB}
> ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o (
> 8669 insns) ./a.ltrans3.o ( 138934 insns)
One problem I see here is that while it is OK for Firefox builds it is
bit too coarse for smaller testcases where the memory use is still
importnat. I guess we may just print KBs before the large gets too
large, just like norton commander does? :)
Honza
>
> Thoughts?
> Thanks,
> Martin
