欢迎!有关此处的更多详细信息,请参阅 关于 页面。
c.c/hash 在处理 Java 集合时始终使用 hashCode,在比较与使用 Murmur3 的 Clojure 集合时产生不兼容性。
user=> (== (hash (java.util.ArrayList. [1 2 3])) (hash [1 2 3])) false user=> (= (java.util.ArrayList. [1 2 3]) [1 2 3]) true
修复此问题的一种方法是在 Util/hasheq 中为 java.util.Collections 添加一个特殊案例,就像现在对 String 所做的那样。
有关此主题的 Clojure 群组讨论链接:https://groups.google.com/forum/#!topic/clojure/dQhdwZsyIEw
评论者:alexmiller
没有补丁的情况下,这些时间是什么样的?
如果我们对不同类型改用 hasheq 而不是使用 instanceof,会怎么样呢?
评论者:michalmarczyk
重载方法在静态解析,所以在 Object 重载中测试类型是不可避免的。
可以更具体地重载,以便在类型提示或字面量给参数类型时加快哈希的速度,因为编译器会根据适当的编译时信息生成调用该重载的调用。然而,在哈希表/集操作中隐式哈希不会有任何速度提升。
评论者:[email protected]
这个问题出现在将 Factual/skuld 从 1.5.1 升级到 1.6 的过程中。clojure.data.fressian 将 c.l.PersistentHashSet 集合序列化为 java.util.HashSet。这破坏了在 https://github.com/Factual/skuld/blob/b720feb142e6d274e85be208dc1d6d8634801719/test/skuld/net_test.clj#L8-L29 中的相等性检查,因为我们正在比较一个包含 PersistentSet 的原始集合和序列化及反序列化后包含 HashSet 的集合。
这个问题又出现了,详细信息见 http://dev.clojure.org/jira/browse/DFRS-7
评论者:mpenet
今天这个问题又对我造成打击(在解决这个问题之前浪费了很多时间)。我们会在 1.7 中解决这个问题吗?
据我所知,我们仍在寻找在可接受的性能影响之前的解决方案。
尽管我们不反对解决这个工单,但我们对此的关注并不愿意以我们更重视的性能比较为代价,并且没有任何当前的建议能达到那个标准。目前,我将此移至待办事项列表,如果出现解决方案,我会将其移出来。