30.4.  Optimizing Everything Else

If you have determined that rendering is not your bottleneck, or if you have already optimized rendering as much as possible and a significant amount of time is still being spent doing something other than rendering, it’s time to look for other bottlenecks.

This section helps you find other bottlenecks, and suggests Open Inventor-specific things to look for by discussing the following:

Standard performance analysis tools make performance analysis of the non-graphics part of your application easy. See the reference pages for information on using these tools.

Open Inventor 8.0 introduces a new .iv Open Inventor file format and several improvements to writing and reading Open Inventor files. Note that all previous versions of Open Inventor since version 2.1, wrote the version 2.1 header by default. In order to take maximum advantage of the new features, Open Inventor 8.0 writes the new header and format by default. Applications built with an older version of Open Inventor will not be able to load these files. However files can be converted using the ivCat tool as described below.

Open Inventor 8.1 added support for reading and writing compressed Inventor format (.iv) files. Loading a compressed file is much faster, especially for large files, because fewer bytes need to be transferred from the physical disk or network.

Open Inventor supports the Deflate compression format, used by zlib and gzip. In order to compress a file, any software which supports gzip compression can be used.

The file extension “.ivz” is suggested for convenience, but compressed IV files don’t need any specific extension in order to be supported by Open Inventor. The compression detection is automatic and there is no need to add extra code to support compressed files. The class SoInput SoInput SoInput natively supports compressed files.

Compression management is performed by the classes SoInput SoInput SoInput and SoOutput SoOutput SoOutput . SoInput SoInput SoInput supports compressed IV files even when the streaming mode is enabled, but the “read from buffer” feature does not support compression at this time. The SoOutput SoOutput SoOutput class has been improved to compress the data on-the-fly. In order to write a compressed file a new file property can be set in any SoOutput SoOutput SoOutput based object.


All applications that use SoInput SoInput SoInput can read compressed files, including the SceneViewer, LargeModelViewer and IvTune.

First, make sure your application isn’t running out of physical memory. If your application is swapping, try to reduce its memory usage as follows:

If memory is not the problem, start by looking at “inclusive” CPU times for your procedures (inclusive times include time spent in that procedure and all procedures it calls; exclusive times are just the time spent in that procedure). Ignore the very highest level routines like main() or SoXt::mainLoop() ; look for Open Inventor beginTraversal() methods or for application routines that are taking a significant percentage of time. If a lot of time is spent in SoGLRenderAction::beginTraversal(), see Section 30.3, “ Optimizing Rendering” for information on improving rendering performance.

If your application is spending a lot of time in code written by you, you are on your own! The rest of this section describes Open Inventor routines that often show up on profile traces, describes what these routines do, and suggests ways of using them more efficiently.

Open Inventor actions perform a lot of work the first time they are applied to a scene (subsequent traversals are very fast). Therefore, if your performance traces show a lot of time being spent inside an action’s constructor or the SoAction::setUpState()method, try to create an action once and reapply it instead of constructing a new action. For example, if you often compute the bounding boxes of some objects in the scene, keep an instance of an SoBoundingBoxAction around that is reused:

static SoGetBoundingBoxAction *bbAction = NULL;
if (bbAction == NULL) bbAction = new SoGetBoundingBoxAction;
bbAction->apply(myScene);
  
static SoGetBoundingBoxAction bbAction = null;
...
if (bbAction == null) bbAction = new SoGetBoundingBoxAction(viewportRegion);
bbAction.Apply(myScene);
  
static SoGetBoundingBoxAction bbAction = null;
...
if (bbAction == null) bbAction = new SoGetBoundingBoxAction(viewportRegion);
bbAction.apply(myScene);
  

instead of the much less efficient:

SoGetBoundingBoxAction bbAction;
// inefficient if called a lot!
bbAction.apply(myScene);
  
          
        
          
        

Every time you change a field in the scene, Open Inventor performs a process called notification. A notification message travels up the scene graph to the node’s parents, scheduling sensors, causing caches to be destroyed, and marking any connections to engines or other fields as needing evaluation.

If your performance traces show a lot of time is being spent in a startNotify() method, try the following to decrease notification overhead:

If your application profiles show a lot of time is spent inside the methods SoHandleEventAction::beginTraversal()or SoPickAction::beginTraversal() , try the following to improve picking and/or event handling performance: