David Megginson wrote:
> I did another run, with a flight of over one hour on autopilot.
> Cumulatively, ssgEntity::cull_test and ssgBranch::cull use nearly 20%
> of CPU time -- that's OK, as long as the framerate improvements
> justify the work.
Yes - that's probably not too bad...but with it narrowed down that
closely, you can probably squeeze some performance out of them.
Probably, most of that time is actually spent in
int sgFrustum::contains ( const sgSphere *s )
...my Scene graph API that I wrote for use at work is quite a but
cleverer about how it does this. The 'contains' test in SG measures
the distance from the center of the sphere to each of the four planes
of the view frustum. In fact, you can improve on this by remembering
which faces of the frustum the PARENT OBJECT SPHERE's passed cleanly
and not bother to test against them in future. You end up needing to
write about 64 different functions - each hand-optimised to test a
sphere against a different combinations of the six faces of the frustum.
Then you can compute a number that indicates to objects lower in the
tree which version of that function to call when they need to test their
spheres.
This results in most spheres' not needing to be tested at all - and for
those that do need to be tested, most need only one sphere-to-plane
calculation.
That's quite a lot of typing - but it's not actually that hard to do.
> I can see room for some easy plib optimizations. For example, the
> program spent 2.95% of its time in ssgVtxTable::getNumVertices, 1.91%
> of its time in ssgVtxTable::getNumColours and 1.8% of its time in
> ssgVtxTable::getNumTexCoords. All of these might be able to be
> optimized to cache the result, rather than counting through the arrays
> each time (if they do that currently), and it looks like the saving
> could be significant.
That certainly seems like a VERY big number - but all of those routines
are simply fetching a member variable via a pointer. They are declared
'inline' - but since they are probably also 'virtual' that may still result
in a function call.
The only way I can imagine they are consuming that much time would be
if they are called a heck of a lot of times.
Probably there are some loops:
for ( int i = 0 ; i < getNumVertices() ; i++ )
...whatever...
...so 'getNumVertices' get called (unnecessarily) in every loop. It
might be worth copying the value into a variable first or even running
the loop backwards to avoid calling the function every time.
> On our side, the biggest hog is FGHitList::IntersectBranch, with 3.96%
> of CPU time. I assume that's calculating the ground elevation, but
> any optimizations might be helpful, if people can think of one.
In my experience, there are often some great ways to optimise those kinds
of functions.
But guys - get this into perspective. If you take a routine that consumes
only 1% of the CPU and you make it go 100 times faster, how much faster
does the program run? Less than 1% faster. It's not worth the effort
to do that unless you think you can get comparable speedups in every
single function in the program.
All you can possibly do is to optimise things that are up there in the
20% range...and even then, you won't do much to improve performance...you'll
never manage to double the speed of the program for example!
If you don't see things consuming considerably more than 20% of the CPU, you
need to look for major *structural* improvements rather than line-by-line
optimisations.
----------------------------- Steve Baker -------------------------------
Mail : <[EMAIL PROTECTED]> WorkMail: <[EMAIL PROTECTED]>
URLs : http://www.sjbaker.org
http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
http://prettypoly.sf.net http://freeglut.sf.net
http://toobular.sf.net http://lodestone.sf.net
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
