在 FP 中管理复杂状态答案

【问题标题】：Managing complex state in FP在 FP 中管理复杂状态
【发布时间】：2018-01-26 23:47:47
【问题描述】：

我想写一个多实体系统的模拟。我相信这样的系统激发了 Simula 和 OOP 的创建，其中每个对象都将保持自己的状态，运行时将管理整个系统（例如停止线程、序列化数据）。

另一方面，我希望能够倒带，更改模拟参数并比较结果。因此，不变性听起来很棒（至少几乎可以肯定由于跟踪可能的冗余数据而导致的垃圾收集问题）。

但是我不知道如何建模。 这是否意味着我必须将每个交互实体放入一个巨大的结构中，每个对象更新都需要首先定位它？

我担心这种方法会因为 GC 开销和不断的结构遍历而不是在内存中保留一个固定的实体地址而严重影响性能。

更新

为了澄清，这个问题询问是否有除了创建一个包含所有可能交互实体作为根的单一结构之外的任何其他设计选项。直观地说，这种结构意味着对数单次更新惩罚，除非更新以某种方式“聚集”以摊销。

是否存在可以对交互进行不同建模的已知系统？例如，像冷/热数据存储优化？

经过一些研究，似乎与 N 体模拟有关，其中系统可以集群，但我还不熟悉。即便如此，这是否也意味着我需要一个单一的集群结构？

【问题讨论】：

嗯您的问题非常模糊和广泛，很难给您具体的建议。你试过任何poc吗？如果不只是实现第一个想法，您可以对其进行测试。
AFRP 可能是一个不错的选择，但如果您对 Haskell 有点陌生，这可能是一个非常陡峭的学习曲线。无论如何，您可能确实需要以某种方式对所有对象进行“全局索引”（RAM 也是全局索引的），并且值得仔细考虑您需要什么样的数据结构。更多细节 -> 更多建议。
OOP 系统是一个巨大的结构，每个对象更新都需要首先定位它，只是间接采用不同的形式。
@ReinHenrichs 我认为问题主要在于这种不同形式的间接寻址有多少开销

标签： haskell functional-programming purely-functional

【解决方案1】：

虽然我同意人们评论这是一个模糊的问题，但我仍会尝试解决提出的一些问题。

确实存在一些不可变性带来的性能开销，因为当您使用可变状态时，您可以就地更新一些值，而对于不可变状态，必须进行一些复制。 p>

然而，一个常见的误解是，这会导致大型“对象”图出现问题。没必要。

考虑一个 Haskell 数据结构：

data BigDataStructure = BigDataStructure {
    bigChild1 :: AnotherBigDataStructure
  , bigChild2 :: YetAnotherBigDataStructure
  -- more elements go here...
  , bigChildN :: Whatever }
  deriving (Show, Eq)

想象一下，这些子元素中的每一个本身都很大而且很复杂。如果你想改变，比如bigChild2，你可以这样写：

updatedValue = myValue { bigChild2 = updatedChild }

当您这样做时，会发生一些数据复制，但通常比大多数人想象的要少。这个表达式确实创建了一个新的BigDataStructure 记录，但它不会“深度复制”它的任何值。它只是重用bigChild1、updatedChild、bigChildN 和所有其他值，因为它们是不可变的。

理论上（但我们稍后会再谈），您的数据结构越扁平，应该启用的数据共享就越多。另一方面，如果您有一些深度嵌套的数据结构，并且需要更新叶子，则需要创建这些叶子的直接父级的副本，以及这些父级的父级，以及它们的父级好吧，一直到根。那可能很贵。

不过，这就是理论，但几十年来我们已经知道，尝试预测软件的性能是不切实际的。相反，请尝试测量它。

虽然 OP 建议涉及大量数据，但它没有说明多少，也没有说明将运行模拟的系统的硬件规格。所以，作为Eric Lippert explains so well，最能回答有关性能问题的人就是你。

附：根据我的经验，当我开始遇到性能问题时，我需要在如何设计我的系统时发挥创意。高效的数据结构可以解决许多性能问题。 OOP 中的情况与 FP 中的情况一样。

【讨论】：