This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Do not add partial_symbol again and again to the list


On Tue, May 06, 2008 at 01:42:41PM -0400, Aleksandar Ristovski wrote:
> I am not, however, happy with the patch completely - I think we can
> optimize it a bit more. Both struct partial_symbol and struct symbol
> are space critical and we should save everything we (reasonably)
> can.
>
> My "feeling" is that we could use struct symbol for both, populate
> only the "partial_symbol" portion and then, as we load full symbols,
> "promote" the existing allocated structures to full symbols; some
> operations would not repeat (like name construction or
> fixup_[p]?symbol_section); initial memory allocation would be
> greater, but in the long run I would expect that gdb would use less
> memory than it does now. Savings I am hoping to see from such
> approach are: overall lower memory consumption, much lower number of
> memory alloc's, and saving some redundant operations we do for both
> psyms and syms.

A symbol is about twice as big as a psymbol.  So this would only lead
to less overall memory if we loaded more than half the full symbols in
an average debugging session.  I just don't think that's true.  It's
probably more like 5%.

And the bcache allows psymbols that look the same to use the same
memory.  It's hugely effective - check maint print statistics.  No
two symbols can share memory for various reasons.  For instance, two
global functions will have different block pointers.

> Or, maybe, we could go step by step: commit this patch (providing
> you find it good enough) and then continue with more extensive
> changes?

I think we should finish up this patch, and then proceed from there.

Should we use this optimization for all global psymtabs?  If so, then
we ought to do it in common code so that all the other symbol readers,
like stabs, benefit.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]