This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: QUIT as a function?
- To: msnyder at cygnus dot com (Michael Snyder)
- Subject: Re: QUIT as a function?
- From: Todd Whitesel <toddpw at wrs dot com>
- Date: Fri, 1 Oct 1999 17:27:16 -0700 (PDT)
- Cc: gdb at sourceware dot cygnus dot com (GDB Developers)
> >Yes, QUIT appears in the inner loops of the symbol readers, which
> >are known to be compute-bound and some of the most time-critical
> >code in all GDB.
>
> True, but there's so much going on in those symbol readers
> (including file accesses) that I can't believe one function call,
> even in the innermost loop, would make a measurable difference.
#define QUIT { \
if (quit_flag) quit (); \
if (interactive_hook) interactive_hook (); \
PROGRESS (1); \
}
Hmm.
Y'know, we could replace all current invocations of QUIT with:
{
static int cnt = 1;
if (!--cnt)
{
cnt = 100;
QUIT;
}
}
On most architectures this would be faster that the current code, and
would insulate the surrounding code from the actual speed of QUIT (to
a point). But somehow I too doubt that the actual speed of QUIT makes
a huge difference in observable performance.
Has anyone simply profiled the symbol code with QUIT as a function vs.
as a macro? That would settle this.
--
Todd Whitesel
toddpw @ wrs.com