确定在场景遍历阶段Geolib3-MT使用多少逻辑核心。

与以前的版本不同，Geolib3-MT使用内部线程池来缩短场景遍历时间。下图演示了Geolib3-MT与以前版本的Katana。

默认值为0，导致Geolib3-MT使用主机上的所有可用逻辑核心。

注意：  虽然核心Geolib3-MT处理引擎会随着核心数量的增加而扩展，但是Op树中的各个Op可能不会表现出相同的缩放特性。线程数增加可能会导致场景遍历时间增加。在这种情况下，可以使用新的配置工具Katana 3.5可用于识别这些操作并优化其行为。标记为Ops的情况也是如此thread unsafe，因为这些要求购买一个Global Execution Lock （GEL），这进一步限制了场景遍历的可伸缩性。

打开后，Geolib3-MT会执行一个预处理步骤，在该步骤中，它会检查Op树的拓扑以识别可以潜在优化的构造。一种优化是将相同类型的Op序列折叠为该Op的单个实例。有许多好处：

• 减少的函数调用开销-调度Op来烹饪场景图位置会涉及少量成本。通过组合相似操作的链，可以减少此函数调用的开销。
• 减少的内存占用-缓存子系统中的10个操作链可占用10个单独的厨师结果，而成功折叠的操作链在每个位置仅占用1个厨师结果。

从最下游的Op观察时，评估Ops折叠链的结果应与评估Ops链相同。

注意：  Op API调用以查询上游场景图结果，例如getAttr()，如果链中的其中一个Ops负责设置该属性，则在折叠链中调用时，不会返回预期结果。在这种情况下，Op应该使用getOutputAttr()代替。

如果调用，Op树优化器会尝试折叠任何相同类型的Ops链GeolibSetupInterface::setOpsCollapsible()在此期间setup()呼叫。此函数的调用者必须指定Geolib3传递给Op的属性的名称cook()作为Op参数调用。此属性包含一个包含有折叠的Ops参数的属性的有序数组（从上游Op到下游Op的顺序）。然后，Op可以适当地处理此批Op参数。

如果关闭，则不会从缓存中清除任何烹饪结果。

小费：  最初，禁用高速缓存逐出似乎是违反直觉的，但是在某些情况下可能合适。当渲染器所需的场景和数据结构舒适地适合内存时，可能就是这种情况。甚至更大的场景也可以从某种程度上受益，因为一旦渲染的场景生成阶段完成，就不再能够访问Geolib3-MT的烹饪结果所占用的内存页面，因此不适合分页到磁盘；由于这些页面在渲染期间不会重新分页到主内存，因此性能损失最小。

如果cacheEviction打开， cacheSoftLimit控制使用最近最少使用的逐出策略逐出条目之前在本地缓存中存储多少烹饪结果。

注意：  尽管可以从本地缓存中逐出这些条目，但可以在多个其他本地缓存或中央（共享缓存）中共享这些条目。在这种情况下，条目的内存将不会立即被回收。

考虑场景图和Op树的最大深度。的cacheSoftLimit每个线程控制最近使用的库克结果缓存的大小。这意味着在特定线程上进行烹饪的任何位置，或在烹饪过程中访问的任何位置（例如通过getAttr()）存储在本地缓存中，并根据cacheSoftLimit。

如果cacheEviction打开， collectionFrequency控制收集周期之间的时间（以毫秒为单位）。在收集周期中，Geolib3-MT收集自上一个收集周期以来逐出的所有缓存条目，如果不再使用烹饪结果，则逐出并回收该烹饪结果的内存。

注意：  减少collectionFrequency间隔会更猛烈地驱逐烹饪结果，从而减少内存占用，但可能会浪费场景遍历时间。

如果启用，则Geolib3-MT首先会完全遍历由Op树中找到的任何源Op（无输入的任何Op）生成的场景。当加载几何缓存或其他资产类型时，此设置可以带来好处。

注意：  经验测试发现，通常在源操作之后进行某种形式的修剪操作。结果，在这些情况下， preCookSourceOps可以生成比所需数量更多的场景图位置，这可能导致增加的内存消耗和遍历时间。

如果打开，Geolib3-MT将在Op树中识别可以并行评估的Op。

一个例子是Merge操作：

Geolib3-MT并行评估每个分支，这可以减少场景遍历时间。