Multiple Threads and Performance

The capability to use multiple threads allows an application to potentially improve performance, even (but not necessarily) on a single processor machine. This is because one thread may become blocked waiting for a resource, such as a disk access, and because one thread may not be able to keep the graphics pipe busy.

Starting with Open Inventor 10, the multithread support is now always activated. It's then more important than ever to use the usual optimization techniques for Open Inventor. For example, one of the benefits of render caching (see SoSeparator) is that it avoids the overhead of scene graph traversal for the cached subgraph. In the multithread case, render caching also avoids the overhead of locking and unlocking mutexes in the cached subgraph. At the same time, there is some additional overhead in using render caches (checking if it is possible to use a render cache and if it is possible to build a render cache). So ideally render caches should contain as large a subgraph as possible (as opposed to caching individual Separators at the “leaf” nodes of the scene graph). Also try to identify cases where caching will never be possible, for example Separator nodes above a camera or 2D text node, and make Open Inventor aware of this by disabling render caching at those Separator nodes. There is no caching overhead for a node where caching is explicitly disabled.

By default notification happens every time a field or child list is modified. If a scene graph update requires modification of multiple fields (or child lists), it is usually unnecessary and inefficient to do notification on every individual change. It is better to disable notification on the affected nodes, make the changes, then trigger notification explicitly. You can do this by calling touch() on a node that has notification enabled.

Disabling notification may not be appropriate if the node has fields
connected to other fields and/or engines.