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] 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


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