From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Jason Molenda Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA] bug in symtab.c:lookup_block_symbol()'s search method Date: Fri, 14 Sep 2001 09:58:00 -0000 Message-id: <87zo7xogj3.fsf@cgsoftware.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> <20010914091241.A28921@shell17.ba.best.com> X-SW-Source: 2001-09/msg00183.html Jason Molenda writes: > 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. Returns to being unmeasurably fast? Try reverting the patch entirely, and see how fast it is. It was a complete linear search for objective c, C++, and java before. No binary search at all. The search was not O-log time before I made the patch, so please don't pretend it's a regression from what was previously there. > > 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. Vague hand-waving? Fine Jason. Whatever you say. I'm unsubscribing from the list, I'm tired of trying to be helpful. > > Jason -- "They say we're 98% water. We're that close to drowning... (Picks up his glass of water from the stool...) I like to live on the edge... "-Steven Wright