Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: drow@mvista.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] bug in symtab.c:lookup_block_symbol()'s search method
Date: Fri, 14 Sep 2001 11:57:00 -0000	[thread overview]
Message-ID: <6480-Fri14Sep2001215412+0300-eliz@is.elta.co.il> (raw)
In-Reply-To: <20010914140051.A20039@nevyn.them.org>

> Date: Fri, 14 Sep 2001 14:00:51 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > 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?
> 
> This much I can mostly agree with, but...
> 
> > 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.
> 
> Maybe you don't.  I'm sure I'm not the only one who would like to start
> eliminating them.

You are not the only one: I also would like them to be eliminated, as
I'm sure is Dan and everyone else on this list.

The issue is not whether to eliminate them, but whether their presence
makes GDB ``broken'' and unsuitable for a release, and whether it
justifies the unfortunate wording seen in this thread that made Dan
feel he is unwanted here.

I think the answer to the last two issues is a qualified NO.

> A lot of operations take frustratingly long that shouldn't.

Yes, we have quite a few operations in GDB that are slow, some of them
painfully slow.  But please do not attack people who wrote the slow
code.  Please let's assume that we all write the best code we can come
up with, and even if someone errs (and we all do), that someone
doesn't deserve to be bashed.

Dan, in particular, has a long history of eliminating slow code from
GDB, and I think he doesn't deserve to be accused in the opposite.

I'm sorry to sound as if I were preaching, but it disturbs me deeply
to see technical discussions to turn into personal flamewar.

> For instance, Jason is probably testing on a machine capable of
> displaying a GUI IDE and running MacOS X.  That means a PowerPC,
> presumably, and at least in the 300MHz-500MHz range.  I do much of my
> native GDB testing on a 50MHz MIPS R5432 board, which is probably on
> the order of thirty or forty times slower.  His ten second delays
> become my five minute coffee breaks.

Every modern program will be slow in a 50MHz machine.  For example,
Emacs will not be able to keep up with the keyboard auto-repeat rate
and scroll the display if you press and hold C-v.

Again, I'm not against eliminating delays, if they keep the code
correct.

> Not if every Step instruction takes ten seconds!  That makes debugging
> practically infeasible.

I disagree.  Many of my colleagues on my day-time job use debuggers
(not GDB) which does take on the order of 5 seconds to step on a fast
machine (a 3-CPU 250MHz SGI box), and none of them thinks it's
infeasible.

Again, please don't misinterpret me: I'm all for eliminating delays.
But taking things out of proportion, and then attacking people based
on those out-of-proportion impressions is something that I cannot say
I care about.


  reply	other threads:[~2001-09-14 11:57 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-09  7:48 Jason Molenda
2001-09-10 11:24 ` Michael Snyder
2001-09-10 11:32   ` Jason Molenda
2001-09-10 11:50     ` Daniel Berlin
2001-09-10 11:52       ` Daniel Berlin
     [not found]       ` <20010910130347.A5628@shell17.ba.best.com>
2001-09-10 14:17         ` Daniel Berlin
2001-09-14  7:53           ` Andrew Cagney
2001-09-14  8:53             ` Daniel Berlin
2001-09-14  9:06             ` Eli Zaretskii
2001-09-14  9:13               ` Jason Molenda
2001-09-14  9:58                 ` Daniel Berlin
2001-09-14 10:55                   ` Eli Zaretskii
2001-09-14 10:52                 ` Eli Zaretskii
2001-09-14 10:59                   ` Daniel Jacobowitz
2001-09-14 11:57                     ` Eli Zaretskii [this message]
2001-09-15  0:54                   ` Jason Molenda
2001-09-15  3:43                     ` Eli Zaretskii
2001-09-15  8:01                       ` Daniel Berlin
2001-09-15  9:09                         ` Eli Zaretskii
2001-09-15 12:36                         ` Daniel Jacobowitz
2001-09-15 12:52                       ` Jason Molenda
2001-09-15  7:54                     ` Daniel Berlin
2001-09-15 13:08                       ` Jason Molenda
2001-09-15 13:33                         ` Daniel Berlin
2001-09-15 13:52                           ` Daniel Berlin
2001-09-15 14:02                             ` Jason Molenda
2001-09-15 14:21                               ` Daniel Berlin
2001-09-16  0:15                               ` Eli Zaretskii
2001-09-17 22:56                                 ` Andrew Cagney
2001-09-17 23:12                                   ` Jason Molenda
2001-09-18  6:21                                     ` Daniel Berlin
2001-09-18  7:32                                     ` Andrew Cagney
2001-09-17 23:18                                   ` Daniel Jacobowitz
2001-09-18  4:51                                     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6480-Fri14Sep2001215412+0300-eliz@is.elta.co.il \
    --to=eliz@is.elta.co.il \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox