From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Molenda To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] bug in symtab.c:lookup_block_symbol()'s search method Date: Fri, 14 Sep 2001 09:13:00 -0000 Message-id: <20010914091241.A28921@shell17.ba.best.com> References: <20010909074800.A8112@shell17.ba.best.com> <3B9D054A.4C3CC2B1@cygnus.com> <20010910113226.A23487@shell17.ba.best.com> <87zo82swwa.fsf@cgsoftware.com> <20010910130347.A5628@shell17.ba.best.com> <8766aq7nki.fsf@cgsoftware.com> <3BA219EF.3000300@cygnus.com> <9003-Fri14Sep2001190223+0300-eliz@is.elta.co.il> X-SW-Source: 2001-09/msg00182.html On Fri, Sep 14, 2001 at 07:02:24PM +0300, Eli Zaretskii wrote: > > I agree with Dan here: I don't think this specific issue can be a > valid reason for saying that GDB is ``broken'' and that ``gdb 5.1 can > not be released'' in its current shape. Unfortunately, this performance issue becomes "breakage" on some platforms. Why, MacOS X just happens to be one. In some of our libraries, there are a lot of these opaque struct pointers in use. Looking up one of those variables requires gdb to sit-and-spin for 5-10 seconds, before realizing that it has no definition. Why does it take 5-10 seconds? Because lookup_block_symbol was changed from a binary search to a linear search for symbols not defined in a given block. After restoring the search to O-log time, the symbol lookup returns to being unmeasurably fast. If you're using GDB in under an IDE and you have a Locals window open, and one of those locals is an opaque structure, whenever you step into our out of that frame, you'll have this 5-10 second delay. Or if you have a stack trace window open and you have some opaque structures in that stack trace, every time that's recomputed you'll see these huge delays. I am hard pressed to not define this as "broken". Particularly when it is easy to fix, despite vague hand-waving of how this is not correct. Jason