james@bigtex.cactus.org (James Van Artsdalen) (02/26/90)
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
kingdon@AI.MIT.EDU (Jim Kingdon) (02/27/90)
OK, kids, here's the story on malloc(). GDB 3.5, if built as
distributed makes 4088 byte malloc's in obstack.c. This is very bad,
because such a GDB uses the range-checking version of malloc, which
causes 4088 byte requests to in fact occupy 8192 bytes. The next
release of GDB 3 will fix this by using 4072 byte requests instead.
Mike Haertel has written a new malloc for GNU, which will be used in
GDB version 4 (and emacs version 19). I'm not distributing it in GDB
version 3 because it has not been extensively tested and therefore
might be buggy.
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).
Obstacks are used for the symbol table, which (if the bug described
above is fixed) supposedly should provide good performance. Not that
I'm sure anyone has looked at it closely for improvements in memory
usage.
In the meantime, someone should volunteer to fix GNU malloc.
I guess if people want to play with the new GNU malloc I can make a
copy available for FTP. Send me mail if interested.pcg@aber-cs.UUCP (Piercarlo Grandi) (03/02/90)
In article <31297@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes:
[ ... about saving space (and also time) avoiding readline in 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
Well, this used to be the text size of the Unix kernel on a PDP-11... :-(.
Or, even worse, I know full screen, Emacs like editors that are smaller.
I am still a stupid minimalist.
--
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