Like fixing bugs or eliminating memory leaks, performance tuning is a
necessary chore during application development. Proper organization and planning can speed up
this chore and make it more pleasant.
This section looks at the steps to take when optimizing
your application, discussing these topics:
Setting a performance goal helps you use your time wisely. Typically, you
should decide on a desired frame rate, such as running at 20 frames per second with a
particular scene. A reasonable performance goal for interactive programs is a frame rate of at
least 10 frames per second. Most users find that frame rate acceptable for most tasks (more is
always better, of course).
When setting a goal, keep in mind the capabilities of your hardware.
If the absolute top speed for drawing polygons on your system is 60,000 unlit, single-color
triangles per second, don’t try to get 10 frames per second while drawing 6,000 lit,
color-per-vertex triangles. Write short OpenGL benchmark programs, or feed test scene graphs to
ivview -p to help set your expectations.
When you apply a performance optimization, make sure that the modification
is really an improvement; don’t assume that all the suggestions made in this (or any other)
document automatically apply to your application. For example, render culling usually increases
performance. However, if you have an application in which all objects are always visible,
render culling actually hurts performance.
Again, keep good records. Record what you do and how much it improves
performance. Try to minimize the number of things you change at any one time; for example, if
you make two “optimizations” and performance goes up by 10%, the speedup might be caused by a
5% improvement for each optimization, or might be caused by a 100% speedup caused by one
optimization and a 90% slowdown caused by the other! It is tempting to read a document like
this, make lots of changes, then see if the application gets faster. This not only wastes time,
it can also be counter-productive.