Performance 拉链在实践中的性能如何，何时使用？

我认为这是一个美丽的想法；它优雅地提供了一种遍历列表或树的方法，并以功能性的方式进行本地更新

逐渐地，成本似乎是合理的。但是遍历数据结构需要在每次迭代时分配内存，其中正常的列表或树遍历只是指针追踪。这似乎很贵（如果我错了，请纠正我）

---

费用高吗？在什么情况下使用拉链是合理的？

我可以提供一个可靠的数据点：John Dias和我有一个比较，我们比较了使用拉链表示控制流图的成本和在目标Caml中使用可变记录字段的成本。我们非常惊喜地发现，使用基于拉链的控制流图的编译器的性能实际上比使用由指针链接的可变记录的传统数据结构的编译器的性能稍好。我们找不到认真的分析工具来确切地告诉我们为什么拉链更快，但我怀疑原因是需要维护的不变量更少，指针分配也相对较少。也有可能优化器足够聪明，能够分摊拉链产生的一些分配成本。在任何情况下，拉链都可以用于优化编译器中，实际上有一点性能优势。

旁白：感谢您将链接发布到该论文，看起来是一本不错的读物。起初我认为这与db有关，因为

performance

标签上有红门图标。有人应该打电话给YKK，让他们知道

zipper

tag.Ah的可用adspace。我想知道那个标志是什么。我以为是瑞奇·瑞维，你的密码有吗？注意，OCaml有一个异常低效的写屏障，它会惩罚命令式代码中的指针写入。