Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!utah-cs!utah-gr!thomas
From: thomas@utah-gr.UUCP (Spencer W. Thomas)
Newsgroups: net.unix-wizards,net.lang.c
Subject: Re: I HATE DBX! I HATE DBX!
Message-ID: <1700@utah-gr.UUCP>
Date: Sat, 8-Mar-86 16:38:50 EST
Article-I.D.: utah-gr.1700
Posted: Sat Mar  8 16:38:50 1986
Date-Received: Mon, 10-Mar-86 20:17:13 EST
References: <4473@think.ARPA> <5895@allegra.UUCP> <169@gsg.UUCP>
Reply-To: thomas@utah-gr.UUCP (Spencer W. Thomas)
Organization: University of Utah CS Dept
Lines: 20
Xref: watmath net.unix-wizards:17139 net.lang.c:8110

In article <169@gsg.UUCP> kathy@gsg.UUCP (Kathryn Smith) writes:
>
After running some tests then recomiling the
>application to use SDB instead, it turned out that DBX requires somewhere
>between 10 and 15 times the memory resources that the same program compiled with
>SDB requires.

The reason for this is that dbx knows so much more about your program.
Basically, you are seeing the difference in the symbol table sizes
between sdb and dbx.  Dbx also has all the type information compiled
into the symbol table.  If you are running programs that are so big you
can only run one dbx at a time, I would look at the sizes of your swap
partitions and how much main memory you've got.  (You didn't say exactly
why you could only run one at a time, but I assume it must be one of
these.)  Usually, big symbol tables come from big programs, and big
programs have a tendency to eventually fill memory.


-- 
=Spencer   ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)