This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Performance optimize large bp_location count
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 14 Oct 2009 16:57:02 -0600
- Subject: Re: [patch] Performance optimize large bp_location count
- References: <20090904201706.GA26300@host0.dyn.jankratochvil.net> <m3r5t7jg88.fsf@fleche.redhat.com> <20091013223510.GA29950@host0.dyn.jankratochvil.net>
- Reply-to: tromey at redhat dot com
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> Still just this way it was a minimal changeset to get the same user
Jan> experience as the best breakpoints-modifying patch could be. After
Jan> other parts of GDB (symbol lookups) get accelerated more work may
Jan> be useful on this part.
This sounds reasonable to me.
Tom> I puzzled over the choice of a sorted array here, wondering if there
Tom> were perhaps some better data structure. A bit of rationale and
Tom> overview in the patch email would go a long way.
Jan> I do not remember it all but probably I just did not consider the
Jan> possibility of an incremental update, I tried the most easy patch
Jan> and it worked. Different data structure would be more appropriate
Jan> for the incremental update.
Thanks for this and your explanations, they were very useful.
Tom> It isn't obvious to me why this finds the leftmost element when there
Tom> are multiple overlapping ones. What am I missing?
Jan> Maybe another comment? (put there one before "if (b->...)")
Thanks.
Jan> 2009-10-14 Jan Kratochvil <jan.kratochvil@redhat.com>
Jan> Performance optimize large bp_location count.
Jan> * breakpoint.c (ALL_BP_LOCATIONS_SAFE): Remove.
[...]
Ok.
Tom