This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Eliminate quadratic slow-down on number of solibs (part 2).
On Wed, May 13, 2009 at 2:27 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Because of that, your "maintenance set ..." suggestion doesn't
>> make sense to me: why would you ever want O(N*N) algorithm when an
>> O(N) one is available?
>
> There was a communication issue somewhere. I didn't suggest that
> we should keep the O(N*N) algorithm. The command was on top of already
> having the O(N) approach...
Ah, sorry I misunderstood you.
To summarize, there are 4 separate changes flying around:
1. The "don't rescan all objfiles over and over looking for ObjC
methods" patch here:
http://sourceware.org/ml/gdb-patches/2009-05/msg00253.html
I just committed that.
2. The "don't rescan all objfiles over and
over looking for _ovly_debug_event" patch here:
http://sourceware.org/ml/gdb-patches/2009-05/msg00255.html
This patch is "ready to commit"; not sure if I need any further
approvals for it.
3. The "don't reset all breakpoints over and over when adding
multiple solibs" patch here:
http://sourceware.org/ml/gdb-patches/2009-05/msg00097.html
This patch feels like a hack, but does save significant additional
CPU cycles (even after patches #1 and #2 above) and transforms
breakpoint reset operation from O(N*N) into O(N) where N is the
number of solibs added "at once" (such as at program startup). It
is not clear how to make this less of a hack :-(
4. Joel's proposal (if I understood it correctly) to extend patch#3
above to add external control of the suppress_breakpoint_reset
variable via "maintenance set/show breakpoint-reset" or some such.
This would allow advanced users to turn off breakpoint reset
even in cases not addressed by patch#3, but they should really
know what they are doing.
Once could easily imagine such a scenario: a program that
dlopen()s 1000s of solibs in sequence. You'd then turn off
breakpoint reset for all but the very last solib. But I can't
imagine a real program actually doing this.
Thanks,
--
Paul Pluzhnikov