Clojurians Log v2

I'm using Clojure/Java 1.10.1 right now, and I might be seeing some performance degradation when using Clojure sets as map keys or set elements, where it seems much slower when using those vs. using integers as keys/elements, even though the sets being used as keys/elements have (identical? x y) = true when they are equal, so I would expect (= x y) to return true as fast as (identical? x y) to return true. Does this ring a bell for anyone in the implementation? I will poke around a bit more to see if I can find something, and report here.

Hmm. Maybe because APersistentSet has equiv() implementation that does not check for identical using == as a fast path?

Huh, I guess I assumed that would be done there.

APersistentMap equiv() also has no such if-identical-return-true-quickly fast path.

APersistentVector equiv() does have such a fast path

nothing has changed with any of this recently afaik - what do you mean by "degradation"?

can you share what you're actually testing? Util.equiv(Object, Object) has the identity check

I'm doing some more investigation to firm up my claims here, or likely figure out that I'm imagining things. I have some code that I think is running quite quickly when I have lots of sets and maps containing longs as set elements / map keys, but I think the same code is noticeably slower when using IPersistentSet's of longs as set elements / map keys.

there were some mailing list posts for many years ago about performance of small collections as keys in maps, I believe inside instaparse

and I don't entirely recall, but I think the gist of it was something like, computing the hash codes for small collections up front would perform better, but clojure generally computes in on demand and caches it

that may predate the hasheq stuff even, so maybe too old

ah, I mis-remembered the whole thing: https://archive.clojure.org/design-wiki/display/design/Better%2Bhashing.html

(and of course last edited by @andy.fingerhut)

Yep, I recall those events. Fun perf debugging! 🙂

I believe this is different than that.

I wonder how SipHash and other more recent non-cryptographic hashes perform

Somewhat relatedly https://openjdk.java.net/jeps/8201462