前几天我发现了Helm（http://helm-engine.org/），我一直在玩它。我喜欢榆树，所以赫尔姆到目前为止一直很好用。 简而言之，更新函数会在每个tick中调用并传递给模型，并且必须返回该模型的更新版本。然后调用另一个函数在屏幕上呈现该模型。
对于模型中不多的小游戏来说，它看起来很理想，但我一直在想一些更大的东西，HashMap（或其中很多）是理想的，我想知道表演。
我不是专家，但我相信使用Data.HashTable.IO应该修改ram中的哈希表而不是在更改时创建新副本，但这与Helm的接口似乎很复杂。这意味着为每个查找使用一个Cmd，每个更改并将其返回到Helmn，然后从一个新的调用更新传递结果，如果你有超过一两个要查找的东西，我想是一个噩梦。
Data.HashMap.Strict（或Lazy？）可能会更好用，但我想每次更改都会创建一个新副本，而GC会在将来某个时候释放旧版本。那是对的吗 ？ 这可能意味着数百个副本然后每帧免费，除非整个事情足够聪明，意识到我没有在更改后再次使用旧的哈希表而只是不复制它。
那么这在实践中如何运作？ （我正在考虑使用HashMap，因为它似乎更容易解决，但我想这也适用于常规列表。）
答案 0 :(得分：2)
我支持关于避免过早优化和基准测试的评论，而不是猜测，以确定性能是否可接受。也就是说，你也有一些具体的问题。
Data.HashMap.Strict（或Lazy？）可能会更好用，但我想每次更改都会创建一个新副本，而GC会在将来某个时候释放旧版本。这是对的吗？
是的，修改后的节点的路径将包含新节点。模数平衡，路径左侧和右侧的子树将由新旧树结构共享（不复制）。
这可能意味着数百份副本然后每帧免费
我不知道你到哪里去了数百个＆＃34;从。你是说有数百个更新？对于某些结构，存在重写规则，允许以变异方式使用大部分中间值。例如，请参阅this small examination of vector。
那么这在实践中如何运作？
在实践中，人们实施他们想要的东西，并返工太慢的部分。我可能会提前到达HashMap，而不是假设容器Data.Map就足够了，但我没有证据就超越了它。