通过建模决策的结果进行思考是确保良好模型性能的关键部分。换句话说，确保计算引擎不会超过。本文重点介绍了如何减少计算引擎负载的一些想法。
公式应该很简单；嵌套或使用多种组合的公式使用有价值的处理时间。编写长长的，涉及的公式会使引擎努力工作。当用户盯着屏幕时，秒数。简单更好。分解公式并使用其他选项有助于快速保持处理速度。
在模型中使用这些技术时，您必须保持平衡，因此指导如下：
- 分解最常见的公式
- 分解最复杂的公式
- 分解您无法解释一句目的的任何公式
具有许多计算成分的公式
公式的结构可以与模型中的输入更改时发生的计算量有显着影响。考虑以下计算应用程序中总利润的示例。有五个要素构成了计算：产品销售，服务销售，销售成本（COG），运营支出（OP EX）以及租金和公用事业。每个不同的元素都在单独的模块中计算。报告模块将结果汇总到总利润订单项中，该项目使用下面显示的公式计算出来。
有一种简单的方法来构建模块来减少对计算引擎的需求。您可以通过为每个组件创建一个订单项，并将总利润公式作为单独的行项目添加总利润公式来分开报告模块中的输入行。这样，更改对源数据仅导致相关行项目重新计算。
例如，产品销售计算的更改仅影响产品销售和报告模块中的总利润界限项目；服务销售，OP EX，COGS和租金和公用事业没有变化。同样，齿轮的变化仅影响报告模块中的齿轮和总利润。
牢记一般指南。将每个下游公式分解为单个订单项是不切实际的。
计划提供公式的早期出口
条件公式（如果/时）就模型构建器的最佳结构是对公式的最佳结构而构成的挑战，而没有使其过于复杂且难以阅读或理解。基本原则是避免使计算引擎的工作量超过必要的工作。尝试设置公式以尽快完成计算。
始终首先放置最有可能发生的状况。这样，计算引擎可以尽早退出表达式处理。
这是评估季节性营销促销的示例：
夏季促销活动持续了三个月，冬季晋升了两个月。
在没有促销的几个月里，这种公式不是最佳的，并且需要更长的时间才能计算。
这是更好的，因为公式将在第一个条件后更频繁地退出。
有一个更好的方法可以做到这一点。遵循上面的原则，添加另一个订单项以无晋升。
然后公式可以变成：
这甚至更好，因为已经计算了没有促销的计算，并且夏季促销比冬季促销更频繁。
并不总是清楚哪种情况会比其他情况更频繁地发生，但是以下是如何优化公式的一些示例：
- Finditem公式
公式的FindItem元素将在整个列表中工作，以寻找文本项目，如果找不到引用的文本，它将返回空白。如果引用文本为空白，则它也将返回空白。在公式的开头插入条件表达式可以防止计算引擎被超额释放。- 如果是iSnotblank（文本），则FindItem（列表，文本）else blank 或者
- 如果空白（文本），则为空白finditem（列表，文本）
- 滞后，偏移，邮寄等。
例如，在某些情况下不需要滞后或偏移数据，例如，如果滞后或偏移参数为0。计算值与所讨论的期限相同。在公式开始时添加条件将有助于消除不必要的计算：- 如果lag_parameter = 0，则0 else lag（lineItem，lag_parameter，0） 或者
- 如果lag_parameter <> 0，则lag（lineItem，lag_parameter，0）else 0
- 布尔人
避免为格式为布尔值的订单项添加不必要的混乱。无需包含真实或错误的表达，因为条件将评估为True或false。- 销售> 0 代替
- 如果销售> 0，那么否则false
