From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Berlin <dan@cgsoftware.com>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: PATCH: fail to improve psymtab memory consumption
Date: Fri, 20 Jul 2001 15:17:00 -0000
Message-id: <87lmljdz4g.fsf@cgsoftware.com>
References: <20010720212013.7DA695E9D8@zwingli.cygnus.com>
X-SW-Source: 2001-07/msg00522.html

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> As Daniel said...
> 
> 2001-07-20  Jim Blandy  <jimb@redhat.com>
> 
> 	* dwarf2read.c (dwarf2_build_psymtabs_hard): Doc fix.
> 
> Index: gdb/dwarf2read.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> retrieving revision 1.29
> diff -c -r1.29 dwarf2read.c
> *** gdb/dwarf2read.c	2001/07/05 16:45:48	1.29
> --- gdb/dwarf2read.c	2001/07/20 21:15:51
> ***************
> *** 977,982 ****
> --- 977,1010 ----
>     info_ptr = dwarf_info_buffer;
>     abbrev_ptr = dwarf_abbrev_buffer;
>   
>+   /* We use dwarf2_tmp_obstack for objects that don't need to survive
>+      the partial symbol scan, like attribute values.
>+ 
>+      We could reduce our peak memory consumption during partial symbol
>+      table construction by freeing stuff from this obstack more often
>+      --- say, after processing each compilation unit, or each die ---
>+      but it turns out that this saves almost nothing.  For an
>+      executable with 11Mb of Dwarf 2 data, I found about 64k allocated
>+      on dwarf2_tmp_obstack.  Some investigation showed:
>+ 
>+      1) 69% of the attributes used forms DW_FORM_addr, DW_FORM_data*,
>+         DW_FORM_flag, DW_FORM_[su]data, and DW_FORM_ref*.  These are
>+         all fixed-length values not requiring dynamic allocation.
>+ 
>+      2) 30% of the attributes used the form DW_FORM_string.  For
>+         DW_FORM_string, read_attribute simply hands back a pointer to
>+         the null-terminated string in dwarf_info_buffer, so no dynamic
>+         allocation is needed there either.
>+ 
>+      3) The remaining 1% of the attributes all used DW_FORM_block1.
>+         75% of those were DW_AT_frame_base location lists for
>+         functions; the rest were DW_AT_location attributes, probably
>+         for the global variables.
>+ 
>+      Anyway, what this all means is that the memory the dwarf2
>+      reader uses as temporary space reading partial symbols is about
>+      0.5% as much as we use for dwarf_*_buffer.  That's noise.  */
>+ 

Hence the reason I only read the part of
the various sections for a given CU (rather than reading the entire
section).  If you look at the new dwarf2 reader, you'll notice we jump
through a few hoops in some places to do this (IE we read a header,
then free it, just to get the size, etc).

I actually use mmap when possible, but that's for speed, rather than
memory savings.

It doesn't buy us anything if we still mmap the entire section, and
then touch every part. :)

--Dan

-- 
"I have a microwave fireplace in my house...  The other night I
laid down in front of the fire for the evening in two minutes.
"-Steven Wright