Re: QUIT as a function?

[Todd Whitesel <toddpw at wrs dot com>]

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