On Sat, Mar 7, 2009 at 2:57 PM, Rich Hickey <richhic...@gmail.com> wrote: > Identity is tested first in equality, if identical, equal, full stop. > So if you are using identical and unique collections as keys you'll > find them without a value-by-value comparison. If they are not > present, it's unlikely you'll get a matching hashCode and a matching > count and a matching long prefix from a mismatch.
But if the key is a long list, wouldn't it have to traverse the list just to come up with the hash code for that list? And doesn't it need that hash code just to know which "bin" to look in for matching keys? If so, then the performance hit occurs before you even get to comparing against other keys. My understanding is that eq?-based associative collections use a completely different hashing scheme, hashing on the address or some other unique/stable value associated with each object, and then use eq? (like identical?) to do the actual comparison when they get to the right "bin". Another use case: Consider sorting a collection of lengthy lists, and you want to sort based on the length of the lists. You want to cache the length of those lists. Using an identity-based hash-map would be the right kind of cache for such a thing, because you're looking up the exact same lists and want to be efficient about it (assuming my comments above about hash performance is correct). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
