This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: ping^2: [patchv2] Fix 100x slowdown regression on DWZ files
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 12 Jan 2015 18:13:22 +0100
- Subject: Re: ping^2: [patchv2] Fix 100x slowdown regression on DWZ files
- Authentication-results: sourceware.org; auth=none
- References: <CADPb22Q2r9Vnne5rDapAy=AuD2AKBU01TRANw3djo5Xk1icvNw at mail dot gmail dot com> <21548 dot 37770 dot 274873 dot 760290 at ruffy2 dot mtv dot corp dot google dot com> <20141002155653 dot GA9001 at host2 dot jankratochvil dot net> <20141231192335 dot GA8188 at host2 dot jankratochvil dot net> <21677 dot 57646 dot 178793 dot 836948 at ruffy2 dot mtv dot corp dot google dot com> <21679 dot 8603 dot 893816 dot 420021 at ruffy2 dot mtv dot corp dot google dot com>
On Fri, 09 Jan 2015 01:32:27 +0100, Doug Evans wrote:
> Doug Evans writes:
> > Do hashtables support calling htab_find_slot with INSERT but then
> > not assigning the slot a value if it was empty?
> > I could be wrong but I think it does.
> > If so, we can remove one call to htab_find_slot here.
>
> I was wrong.
> I thought I was, but I couldn't remember, and couldn't remember where
> I had seen this. But htab_find_slot_with_hash does assume
> that if you call it with INSERT, and the slot isn't already used,
> then you're going to fill in the slot.
> No matter, it was just a thought.
Maybe one could use HTAB_DELETED_ENTRY in such case?
But I find that needless microoptimization. This is solved by compilers this
century. And much faster avoiding all the pointer dereferences which is all
that matters.
But I can use at least htab_find_slot_with_hash instead of htab_find_slot.
Jan