...

Force Serial

The first tool is an attribute to control the depth of parallelism in your scene: forceSerial.

...

Each thread has it's own Geolib runtime containing per-thread caches of cooked locations. As a result all locations needed for any Op would to be cooked per-thread. Continuing with the above example: if you have three threads each looking at different locations under "/root/world/geo", you'll see "/root" cooked three times, "/root/world" cooked three times and "/root/world/geo" cooked three times. If you are running serial, or forcing the parallel traversal to one thread at "/root" then you'll only have one Geolib runtime cooking the location and so would see only a single print from that Op at "/root"

Evict Here

The second tool we have for parallel traversal efficiency is the evictHere setting. 

By default siblings of a Katana scenegraph location will be evicted from a thread's runtime memory when a location is processed for conversion to the Rix scenegraph. Setting this flag false prevents sibling eviction at this location in the event it is known that those siblings are best kept in the cache for subsequent access.

Flatten Instance Source

The last tool is the flattenInstanceSource setting.

Rather than changing the behavior to RfK's parallel traversal of the Katana scene, this setting improves RenderMan's traversal when building instances.  By default, RenderMan flattens an instance source into separate object masters for each geometric primitive in the group. This can get expensive as the number of instances increases or as the number of primitives inside the instance source increases.  Setting this option to Yes will tell RenderMan to keep this instance source location as a single object master.

This setting will override the global setting for prmanGlobalStatements.plugin.flattenInstanceSources - which can enable this setting on all instance source locations.