I haven't taken the time to verify these statements with microbenchmarks, but there are 2 reasons why keywords should have efficiency advantages over strings when used as hash map keys:
(a) For keywords, hash values are calculated and cached when the keyword is first constructed. When looking up a keyword as a hash key, it simply returns the precomputed hashed value [1]. For strings, the hash is recalculated on every lookup [2]. (b) The common case after the hash value is calculated, if the key exists is to compare against a single candidate key in the hash map. For string = between the same strings, but not identical, this is slower than identical?. For = between the same keywords, they are guaranteed to be identical? and thus fast to compare for =. For array map keys (for smaller maps, usually with at most 8 key/value pairs), I can't think of much of a reason that keys would be faster than strings, except for the final = comparison if/when a matching key is found. [1] https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Keyword.java#L87 [2] https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Util.java#L171 On Sat, Oct 11, 2014 at 4:27 PM, Colin Fleming <colin.mailingl...@gmail.com> wrote: > Does this mean that keywords don't have any efficiency advantages over > strings when used as map keys? > > On 12 October 2014 02:25, David Nolen <dnolen.li...@gmail.com> wrote: > >> As already mentioned use identical? In ClojureScript you must use >> keyword-identical? for fast comparisons. >> >> >> On Friday, October 10, 2014, Jony Hudson <jonyepsi...@gmail.com> wrote: >> >>> Hi All, >>> >>> I've been optimising a piece of code lately, and have come to wonder >>> about the performance of keyword comparison. Specifically, I'm not sure >>> whether the performance I'm seeing is what is expected. The data structures >>> page on clojure.org [1] indicates that keywords "provide very fast >>> equality tests". If I micro-benchmark with criterium, then I find the >>> following: >>> >>> As a baseline, comparing integers with `(= 0 1)` takes around 4ns. >>> >>> Comparing keywords with `(= :plus :minus)` takes around 30ns. >>> >>> This is about the same amount of time it takes to compare strings, `(= >>> "plus" "minus")`, which comes in at about 25ns. >>> >>> This surprised me, as I would have guessed that "fast" would have been >>> closer to the integer performance than the string performance. It's worth >>> saying that I don't know a lot about benchmarking, but I do have some >>> "real" code that's performance depends heavily on comparisons, and it seems >>> to line up performance-wise with these micro-benchmarks. >>> >>> So, am I doing something silly (like I don't know about the fast = for >>> keywords)? Or, are my expectations wrong, and this is about how long "fast" >>> should be? Or is there a performance bug lurking? >>> >>> I'm using Clojure 1.6.0 (but have tried 1.5.0 and 1.7.0-alpha1 with >>> similar results). >>> x86_64 Mac OS X 10.9.5 4 cpu(s) >>> >>> Java HotSpot(TM) 64-Bit Server VM 25.5-b02 >>> >>> Thanks in advance for any input, >>> >>> >>> Jony >>> >>> [1] http://clojure.org/data%5Fstructures >>> >>> -- >>> 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 >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> 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 >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> 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 >> Note that posts from new members are moderated - please be patient with >> your first post. >> 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 >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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 > Note that posts from new members are moderated - please be patient with > your first post. > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 Note that posts from new members are moderated - please be patient with your first post. 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
