I've done some experiments with inlining this morning. First I blindly
removed all of the inline keywords from all JSBSim headers, then
compiled with -O2 -fno-default-inline. For the c172 in a 300 sim second
run of steady-level flight following a trim, this required right at 3
seconds.
The same run with the inlined code (as it is in CVS), the same run
required about 1.4 seconds, or IOW, about a 50% reduction.
Profiling the un-inlined code showed that the best candidate for
inlining seemed to be FGColumnVector3::operator()(int), and sure
enough, inlining that brought the time down to just over 2 seconds.
Just going by the order in which they appeared in the profile, I tried
inlining several more and saw only small improvements. This leads me to
believe that the remaining 0.5 second must be just the sum total of
inlining the remainder of the code that is inlined in CVS now.
One counterintuitive result I saw was that inlining
double Getqbar (void) const { return qbar; }
and others like it actually resulted in a speed loss. I'm not
sure why, it may be due to the fact that they are primarily accessed
through tie'd properties. I would need to repeat this experiment on
the pre-properties JSBSim code to find out.
Also, I was able to better quantify the performance change due to
incorporating the properties code. Prior to this, I had done speed
comparisons with the profiling code compiled in, but now I'm not so sure
that's fair. So:
pre-props: 1.3 seconds average
post-props: 1.4 seconds average
or about an 8% loss in speed.
--
Tony Peden
[EMAIL PROTECTED]
We all know Linux is great ... it does infinite loops in 5 seconds.
-- attributed to Linus Torvalds
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
