问题陈述
当在列表上使用累积时（这是使用格式累积（x，y，z）时）的性能可能会很差，任何东西都超过几百万个单元。这是因为该函数在单个CPU线程上运行，这与几乎所有的Anaplan函数不同。Anaplan从CPU上的高水平并发多线程中获得其效率，在此，计算被分解为许多可以并行运行的较小任务，因此它可以更快地运行。
这是一个简单的例子要说明。
图A显示了在单个线程上运行的10秒计算。
图B显示了相同的计算分为10个较小的任务，因此仅需一秒钟即可运行。Anaplan服务器可以使用100多个线程来提高这样的效率。
测试
在测试中，我发现累积超过200万个细胞花费了约0.5秒，而2000万个细胞计数花费了约5.5秒。随着细胞计数的进一步上升，持续时间增加。5000万个细胞计数可能需要40到50秒。随着细胞计数的增长，计算和存储器处理的效率降低，因此我们在细胞计数和持续时间之间没有线性关系。
因此，建议是，几百万个单元可以使计算不到一秒钟。请记住，该计算可能是计算链的一部分，其其他订单项取决于累积计算的值，这意味着这可能会增加等待这些计算的等待，从而增加了整体持续时间。
对于更大的东西，我建议随着时间的推移使用累积。该功能可以是多线程，与累积列表中的单个大任务相比，时间表中的每个周期都是单独的计算任务。这意味着它可以更有效，包括许多可以分割的较小计算与一个单个计算。
这是我运行的一些测试数据：
细胞计数 |
持续时间（SEC） |
％ 减少 |
|
累积列表 |
84,800,000 |
29.82 |
|
随着时间的流逝 |
83,200,000 |
1.01 |
96.6 |
分析
如果我们查看对此的计算分析，我们可以看到，随着时间的推移计算实际上可以做更多的工作。总计算时间要高得多。查找计算（新值）还需要额外的时间将计算出的值从基于时间的订单项回到原始格式。
当我们考虑多线程时，额外的处理似乎并不是那么糟糕。这里的持续时间是秒。
按时间行的源数据此处用于通过映射将原始数据带入基于时间的模块中（因此我们可以累积它）。即使有额外的两个计算，映射查找，总体计算时间也比单线读取的原始累积订单项要小得多（在列表上进行累积）。
解决方法
在列表上进行累积的原因是因为源数据是由列表尺寸而不是随着时间的推移尺寸的。在我用于此测试的模型中，其中一份列表代表数周，幸运的是，有52个列表项目。这使我们可以轻松地映射到一年的时间范围内。
累积列表行项目具有此公式：
累积（来源数据。值，false，自定义周）
它正在从源数据中累积值。自定义周列表上的值。
原始源数据由三个列表尺寸：自定义周，订单，产品。
需要使用用于原始累积的列表（自定义周）的列表中的映射将数据放入基于时间的模块中。
现在，我们在此模块尺寸中使用了三个维度的数据，重复了原始源模块，但使用时间维度替换自定义周。
映射模块的订单项尺寸为1年，时间尺度和周期。自定义周的值按列表顺序映射到时间表周。这可能是任何列表，碰巧我拥有的模型是代表周的列表。
这使我们可以查找与映射的时间表周相匹配的源数据定制周价值：
源data.values [查找：自定义周映射。custom周]
可以创建一个与此新源数据相同的新系列项目，以便随着时间的推移累积：
累积（按时间源数据源数据）
要将数据放回与原始订单项相同的尺寸中，我们需要使用反向映射进行另一个查找：
随着时间的推移累积[查找：定制的周至周映射。周刊]
映射模块与以前的映射相反，该映射模块由台词尺寸定制周与以前的映射匹配的值。
这是蓝图视图中的三个订单项：
作为一个直接的解决方法，您只需要映射您打算在时间段上累积的列表，然后随着时间的推移累积（如果需要的话，则使用映射查找，以将值放在所需的维度中）。期间的类型无关紧要。这只是使用时间复制列表顺序的映射。
