Re: more info on gdb3.5 memory bloat

Thread View: gnu.gdb.bug

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Piercarlo Grandi Thu, 22 Feb 1990 15:01

#855

Author: Piercarlo Grandi
Date: Thu, 22 Feb 1990 15:01

27 lines
1918 bytes

In article <9002172100.AA17438@labgre.HP.COM> glenne@HPLSLA.HP.COM (Glenn Engel) writes:
  Re: previous bug report about gdb using significantly more memory than
      gdb3.4.
  
  When reading my executable's symbol table, malloc is called 841 times
  to request 4088 bytes.  After every one of these 4088 byte malloc calls,
  the data segment size goes up by 8192 bytes.

Maybe you should use the malloc() I have posted time ago in alt.sources.
I will be reposting it to comp.sources.misc soon.

Malloc()s like the GNU one that are based on the Caltech one use a kind
of buddy system, in the vain hope this will make them fast. The only
result is that they become much less space efficient.

Another thing, entirely different: I will be posting shortly some simple
patches to GDB main.c that avoid including readline and company. This
library consumes about 30% of the code space of GDB. I don't need it,
because I have history processin as a line discipline in my tty
driver (thanks to A. Shepherd's CLED). There are also a lot of other
solutions to the line editing/history problem, such as using rk, atty,
or any editor with shell buffers, and under these readline is useless as
well.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk

Re: gdb3.5 & malloc(3c)

#862

Author: James Van Artsdalen
Date: Mon, 26 Feb 1990 04:18

35 lines
1843 bytes

In <1659@aber-cs.UUCP>, pcg@cs.aber.ac.uk (Piercarlo Grandi) wrote:

> Malloc()s like the GNU one that are based on the Caltech one use a kind
> of buddy system, in the vain hope this will make them fast. The only
> result is that they become much less space efficient.

For the record, on SysVr3.2, i386v, I got the following results
running gdb on cc1, compiled with full debugging.  A page is 4K bytes.

Which malloc	Pages	 CPU
------------	-----	 ---
GNU malloc	1466	 :23
libc malloc	 780	1:45
-lmalloc	 762	 :25

My recommendation is to just have SysV set GNU_MALLOC to -lmalloc for
now.  In the meantime, someone should volunteer to fix GNU malloc.
gdb doesn't have a bug as far as I am concerned, although one fix
might be to use a special "malloc" for reading in the symbol table, or
to just use brk(2).

> Another thing, entirely different: I will be posting shortly some simple
> patches to GDB main.c that avoid including readline and company. This
> library consumes about 30% of the code space of GDB.

On my system, it hardly seems worth the effort:

$ size *.o
funmap.o: 400 + 1140 + 0 = 1540
history.o: 6792 + 228 + 0 = 7020
keymaps.o: 532 + 3108 + 0 = 3640
readline.o: 19920 + 1020 + 0 = 20940
-- 
James R. Van Artsdalen          james@bigtex.cactus.org   "Live Free or Die"
Dell Computer Co    9505 Arboretum Blvd Austin TX 78759         512-338-8789

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads