Re: [RFA] bug in symtab.c:lookup_block_symbol()'s search method

["Eli Zaretskii" <eliz@is.elta.co.il>]

> Date: Fri, 14 Sep 2001 09:12:41 -0700
> From: Jason Molenda <jason-swarelist@molenda.com>
> 
> > 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.

Even if the performance hit is significant, I fail to understand how
can someone say the entire program is broken, or that it cannot be
released.  Can we please get things back into their proportion?

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

On what machine?  Timing data is useless without saying on what kind
of CPU and with what clock speed did you see that.

Anyway, I don't consider 5-10 seconds such a long time.  We still have
in GDB operations that take much more, and we don't consider it
``broken'' because of that.

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

So display the hourglass for 10 seconds and be done with that.  No one
will really notice, except you and me.  The world is full with good
software that sometimes has 10-sec delays, to say nothing of bad
software.

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

I'd urge everyone to please stay calm and technical, and avoid
offending others by careless wording.  Please!  Can we disagree but
still stay friends?