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 v2 9/9] add short-circuit logic to elfread.c


On Mon, Oct 21, 2013 at 11:50 AM, Tom Tromey <tromey@redhat.com> wrote:
>>> Nope.  I can add it back somehow if you need it.  Though at the same
>>> time I would like to know what you use it for.  I never figured out how
>>> the current statistic could be useful.
>
> Doug> I don't "need" it, it's just good data and was curious.
>
> The distinction I was trying to draw wasn't whether it was needed or not
> needed, but whether it was useful and if so, what for.  I read your
> response here as saying it is useful.  But could you explain what for?
> What use is there for it?
>
> I understand wanting to know the size of the table that is actually
> constructed.  This is good for seeing where all the memory goes.  But I
> never thought of a use for "number of minimal symbols we discarded".

The comments in the code suggest, to me, the compaction is important.
Well, how important?
[I realize there are reasons for the compaction other than speed,
but according to the comments speed is a real concern here.]

The comments say for gdb the table is reduced by 1/3.
ref: "over a 1000 duplicates, about a third of the total table size"
The comment is a bit out of date (or was miscalculated at the start),
I see 0.1%.
The comment dates back to at least gdb 4.18.

On one of my standard benchmark apps of 1M symbols it is reduced by 0.2%.


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