Andy Ross writes:
> It's probably not a quirk. Inlining actually helps very little except
> for VERY small functions. It used to be that a function call was slow
> -- you had to spill a bunch of registers and a return value onto the
> stack, and then clean them up later. But modern processors can, for
> the most part, stick all that mess into into a few extra pipeline
> stages.
Yes, that was my guess, too. When the method was just a straight
getter, like
inline double get_foo () const { return _foo; }
inlining didn't seem to hurt much (and in a couple of cases it made a
very tiny speed improvement), but once the inlined code had a couple
of lines, either in itself or indirectly by invoking other inlined
code from the standard library headers, inline caused a significant
slowdown (sometimes >25% in a tight loop). That happened even in the
inlined code wasn't invoked, i.e.
inline void foo ()
{
SG_LOG(SG_GENERAL, SG_ERROR, "An error");
}
then
bool flag = false;
if (flag)
foo();
// some other stuff
I was surprised by how much faster things like this ran when I
un-inlined foo().
The build-time problem that Andy mentions has two causes: one is the
code inlining, and the other is the simple fact that so many modules
still include headers from so many other modules. Curts FGGlobals and
my property stuff is an attempt to get rid of (a lot of) that, but the
cleanup has only started. It might be some consolation to Andy that
things used to be much worse.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
