IO之外的Data.HashMap性能

Posted 2021-04-20

我前几天发现了Helm（http://helm-engine.org/），我一直在玩它。我喜欢榆树，所以赫尔姆到目前为止一直很好用。简而言之，更新函数会在每个tick中调用并传递给模型，并且必须返回该模型的更新版本。然后调用另一个函数在屏幕上呈现该模型。

对于模型中不多的小游戏来说，这似乎是理想的，但我一直在想一些更大的东西，HashMap（或其中很多）将是理想的，我想知道它的表现。

我不是专家，但我相信使用Data.HashTable.IO应该修改ram中的哈希表，而不是在更改时创建新副本，但这与Helm的接口似乎很复杂。这意味着为每个查找使用一个Cmd，每个更改并将其返回到Helmn，然后从新的调用更新传递结果，如果您有多于一两个要查找的内容，我将使用这个噩梦。

Data.HashMap.Strict（或Lazy？）可能会更好地工作，但我想每次更改都会创建一个新副本，GC会在将来某个时候释放旧的副本。那是对的吗 ？这可能意味着数百个副本然后每帧免费，除非整个事情足够聪明，意识到我没有在更改后再次使用旧的哈希表而只是不复制它。

那么这在实践中如何运作？ （我正在考虑使用HashMap，因为它似乎是更简单的解决方案，但我想这也适用于常规列表）。

答案

我支持关于避免过早优化和基准测试的评论，而不是猜测，以确定性能是否可接受。也就是说，你也有一些具体的问题。

Data.HashMap.Strict（或Lazy？）可能会更好地工作，但我想每次更改都会创建一个新副本，GC会在将来某个时候释放旧的副本。那是对的吗 ？

是的，修改节点的路径将包含新节点。模数平衡，路径左侧和右侧的子树将由旧的和新的树结构共享（不复制）。

这可能意味着数百份副本然后每帧免费

我不确定你从哪里得到“数百”。你是说有数百个更新？对于某些结构，存在重写规则，允许以变异方式使用大部分中间值。例如，参见this small examination of vector。

那么这在实践中如何运作？

在实践中，人们实现他们想要的东西并且返工太慢的部分。我可能会提前到达HashMap，而不是假设容器Data.Map就足够了，但是如果没有证据我就不会超越它。