Where am I

24.7. Multiple Threads and Performance

The performance of your application will not automatically improve by using multithreaded Open Inventor. 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. In fact, an unmodified program might experience slightly lower performance with multithread support enabled. This is because there is overhead for locking and unlocking mutexes while traversing or modifying the scene graph. For this reason, multithread support is not enabled by default. If you don’t need multithread support, don’t enable it (continue to use the classic SoXt::init() or SoDB::init() ).

When multithread support is enabled it is even more important to use the usual optimization techniques for Open Inventor. For example, one of the benefits of render caching (see SoSeparator SoSeparator 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.

There is additional overhead for Open Inventor “notification.” It’s always a good idea to minimize this overhead, but even more important when multithread support is enabled. 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.