在 Emacs Lisp 中使用 obarray 而不是哈希表有什么好处吗？答案

【问题标题】：Is there any benefit to using an obarray rather than a hash-table in Emacs Lisp?在 Emacs Lisp 中使用 obarray 而不是哈希表有什么好处吗？
【发布时间】：2014-10-02 06:23:11
【问题描述】：

我有一个 Emacs Lisp 程序，它需要跟踪一组字符串，使用它们完成并测试其他字符串是否属于该组。在大多数没有内置 set 类型的语言中，我会使用带有虚拟 t 或 1 值的字典或哈希表，但我想到 Elisp 的 obarray 类型也可以用于目的，用intern、intern-soft 和unintern 代替puthash、gethash 和remhash。

（我知道 cl-lib 函数将列表作为集合进行操作，但这些函数与这个问题并不特别相关，只需要一个集合成员资格测试）。

在现代 Emacs 中使用 obarray 而不是哈希表是否有任何优势（在速度、内存使用或其他方面），或者除了主符号表之外的 obarray 更多是 Emacs Lisp 之前的遗留物吗？哈希表类型？

【问题讨论】：

从我读到的。你所能做的就是在一个新的 obarray 中的 intern 和 unintern 值，但是没有办法访问或修改与符号关联的值。
这不太对——你可以像普通符号一样使用symbol-value和set：(let* ((o (make-vector 11 0)) (s (intern "s" o))) (set s 'value) (symbol-value s)) → value。但在这种情况下，无论如何，实习和取消实习就足够了。
我怀疑 obarray 在表示集合时可能比散列表更节省空间，因为散列表浪费了每个键的单个值槽，而 obarray 浪费了至少三个，因为每个符号都有一个值、函数和 plist 槽。

标签： emacs elisp

【解决方案1】：

由于两者都有效，这在很大程度上是品味或性能的问题。

在内存使用方面（以字数计算），obarray 使用 1 个固定大小 N 的数组加上每个条目一个符号（大小为 6），而哈希表的大小大约为每个元素 5再加一点。所以从记忆上来说，这是一次洗礼。

在速度方面，我不知道有人费心去测量它，所以这可能也不是什么大问题。

IOW，这是一个品味问题。 FWIW，我更喜欢提供更多选项的哈希表；在我看来，obarrays 在很大程度上是一个历史性的意外。

【讨论】：

感谢您的详细解答。我很想知道内存使用情况大致相同，这是我没有预料到的。