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 differ
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):
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
> removi
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 inl
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
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 wher
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 c
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 internal
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, b
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 t
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 process
On Sun, 2002-03-17 at 19:05, David Megginson wrote:
> I've been running some experiments on the property manager today,
> retrieving different kinds of double properties in a tight loop and
> timing the results (the worst case was 6.2 seconds for 100M accesses
> of a property tied to object method
On Sun, Mar 17, 2002 at 10:06:46PM -0800, Andy Ross wrote:
> 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
>
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
> 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
15 matches
Mail list logo
