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 internally,
so the differences are even greater now.
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 sec
Internal (1:1 get:set ratio): 3.74 sec
Internal (10:1 get:set ratio): 3.07 sec
Even when I copy the property value once for every access, it's much
faster than tying to methods. When I set once for every 10 accesses
(probably typical for the more popular properties), there's almost no
additional overhead.
I am trying to find ways to optimize tied methods, but I haven't found
any way yet to handle them without excessive indirection, because of
the necessity of instantiating a template for each different
class/type combination. I should be able to get tied pointers working
as fast as internal methods, though, if we decide to keep those.
> I found only a slight improvement by un-inlining several of the most
> called object methods in JSBSim. The profiling did show less time spent
> in SGPropertyNode::getDoubleValue, but more time in the un-inlined
> getters.
Yes, that was mainly just a matter of making the profiling report more
accurate. Remember that my tests were just for the speed of property
accesses (hence the focussed, tight loop). If we made property
accesses 25% faster, and they accounted for, say, 1% of program
execution time, we'd see only a 0.25% speed improvement.
> In terms of total execution time, I'd say it came out about the same.
> A real gain might be had if I un-inlined more tied methods, I don't
> know at this point.
Even if uninlining the methods kept the speed the same, it would be a
good idea -- the JSBSim executable will be smaller and GDB will be
able to report the current position more accurately. The only reason
not to do it would be if uninlining caused a serious performance hit.
As I mentioned before, the only methods that seem to work well inlined
are ones that simply resolve to variables, like
double get_foo () const { return _foo; }
void set_foo (double foo) { _foo = foo; }
Even here, the advantages are very slight; anything more complicated
seems to slow things down.
This is all separate from the issue of the property manager, of course.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
