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
On Mon, 2002-03-18 at 04:32, David Megginson wrote:
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
Jon Berndt writes:
I had been concerned
that SGPropertyNode::getDoubleValue was showing up at the top of the
profiling output for JSBSim, but I think that that was masking the
object methods it was invoking in other JSBSim code.
Could very well be.
properties, but not much
Tony Peden writes:
To get the equivalent of tieing to object methods, a once-per-frame data
copy is necessary. Did your testing take this into account?
No, I was just testing access time. I checked in some optimizations
that skip a lot of unnecessary code when the value is held
David Megginson writes:
Tony Peden writes:
To get the equivalent of tieing to object methods, a
once-per-frame data
copy is necessary. Did your testing take this into account?
No, I was just testing access time. I checked in some optimizations
that skip a lot of unnecessary code when
David Megginson writes:
Without
inlined methods, we'll probably end up with a smaller fgfs executable,
more accurate debugging information, faster build times, and more
readable headers, etc.
If we default to out-of-line code, then we can profile later and
inline only in the spots where it
Norman Vine wrote:
clarifying my earlier post
Also note that most FGFS functions are only called
at most !
once or twice per iteration of the main loop
A 'few' more 'interesting' ones are called MANY TIMES
per iteration of the loop. IMHO these if they meet the
above criteria are
GOOD
David Megginson wrote:
Tony reported back to the list on a more organic test -- he un-inlined
the most common inline methods in JSBSim, and discovered a slight (but
not exciting) speed *increase*.
Actually, my interest would be in a different benchmark: how much does
removing all the
Andy Ross writes:
Tony reported back to the list on a more organic test -- he un-inlined
the most common inline methods in JSBSim, and discovered a slight (but
not exciting) speed *increase*.
Actually, my interest would be in a different benchmark: how much does
removing all
David Megginson [EMAIL PROTECTED] said:
Here are some tests I just ran, for 100,000,000 accesses of a double
property (I ran each on a few times then picked the most typical user
time; there was little variation anyway):
Tied to object methods: 5.880 sec
Internal (access only): 2.870
Andy Ross [EMAIL PROTECTED] said:
David Megginson wrote:
Tony reported back to the list on a more organic test -- he un-inlined
the most common inline methods in JSBSim, and discovered a slight (but
not exciting) speed *increase*.
Actually, my interest would be in a different
I had been concerned
that SGPropertyNode::getDoubleValue was showing up at the top of the
profiling output for JSBSim, but I think that that was masking the
object methods it was invoking in other JSBSim code.
Could very well be.
properties, but not much for anything else. The biggest
David Megginson wrote:
The biggest surprise was that inlining methods made things slower, not
faster, in most cases (there were a couple of exceptions). That may
be a quirk of G++'s code generation, but it's probably worth
considering -- I had inlined much of the infrastructure to try to
13 matches
Mail list logo
