From: Jan Hubicka <hubicka@ucw.cz>
To: "Martin Liška" <mliska@suse.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 2/3] Use MiB unit when displaying memory allocation.
Date: Tue, 1 Sep 2020 16:04:32 +0200 [thread overview]
Message-ID: <20200901140432.GD13145@kam.mff.cuni.cz> (raw)
In-Reply-To: <1c922586-9b54-61cb-473b-455455413dd2@suse.cz>
> 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
next prev parent reply other threads:[~2020-09-01 14:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-01 12:31 [PATCH 1/3] Support new mallinfo2 function Martin Liška
2020-09-01 12:32 ` [PATCH 2/3] Use MiB unit when displaying memory allocation Martin Liška
2020-09-01 14:04 ` Jan Hubicka [this message]
2020-09-02 13:28 ` Martin Liška
2020-09-17 21:57 ` Jeff Law
2020-09-22 7:47 ` Christophe Lyon
2020-09-22 8:30 ` Martin Liška
2020-09-22 13:02 ` Marek Polacek
2020-09-22 13:24 ` Marek Polacek
2020-09-01 12:33 ` [PATCH 3/3] Use more ONE_? in GGC functions Martin Liška
2020-09-02 13:29 ` Martin Liška
2020-09-17 21:57 ` Jeff Law
2020-09-01 13:38 ` [PATCH 4/N] Change timevar memory allocation to MiB Martin Liška
2020-09-02 13:29 ` Martin Liška
2020-09-02 13:28 ` [PATCH 1/3] Support new mallinfo2 function Martin Liška
2020-09-17 21:56 ` Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200901140432.GD13145@kam.mff.cuni.cz \
--to=hubicka@ucw.cz \
--cc=gcc-patches@gcc.gnu.org \
--cc=mliska@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).