Clojure is caching protocol implementations explicitly with extra bytecodes, not the JVM. And it is very efficient.
I don't think satisfies? is worth optimizing as using ton of it seems antithetical to protocols. It signals to me that a caller does in fact care about the implementation, whereas protocols are about not caring. Like your PR, if you want to ensure a protocol's coverage, you can also extend a protocol to Object and/or nil. Not sure what a valid use case would be for calling satisfies? on a hot path would be. On Thursday, January 22, 2015 at 11:46:02 PM UTC-5, Michael Blume wrote: > > Wait isn't this caching? > https://github.com/clojure/clojure/blob/master/src/clj/clojure/core_deftype.clj#L480 > > On Thu Jan 22 2015 at 8:44:09 PM Bobby Eickhoff <beic...@gmail.com > <javascript:>> wrote: > >> Clojure isn't doing the caching. The JVM is doing the caching. In this >> case, Clojure just has mechanical sympathy for how the JVM operates. >> >> >> On Thursday, January 22, 2015 at 11:10:56 PM UTC-5, Michael Blume wrote: >> >>> It sounds like basically dispatch is fast because we bothered to make it >>> fast (by caching) and satisfies? is slow because we didn't. Is it worth >>> throwing caching at satisfies? to make it fast or should satisfies? just >>> not be on the critical path for Clojure code? >>> >>> (To give a motivating example, satisfies? is on the critical path for >>> honeysql and will be until this pull is merged: https://github.com/ >>> jkk/honeysql/pull/38) >>> >>> >>> On Thu Jan 22 2015 at 5:52:13 PM Ghadi Shayban <gsha...@gmail.com> >>> wrote: >>> >>>> Protocol call sites build an inline cache to optimize dispatch. The >>>> benchmark is running many times and reaping benefit from the cache. >>>> satisfies? looks up the object's class in the protocol's implementation >>>> map [1], and the benchmark is stressing this. You'll see that code checks >>>> if the protocol has the backing interface first, then checks for the >>>> object's class, then if necessary walks up the superclass chain. >>>> >>>> [1] https://github.com/clojure/clojure/blob/master/ >>>> src/clj/clojure/core_deftype.clj#L507-L516 >>>> >>>> >>>> >>>> On Thursday, January 22, 2015 at 8:36:23 PM UTC-5, Michael Blume wrote: >>>> >>>>> Extends seems to be defeated by superclassing. ie: >>>>> >>>>> (extends? my-protocol (class {})) => false >>>>> >>>>> because my-protocol is extended to IPersistentMap and (class {}) isn't >>>>> IPersistentMap it's PersistentArrayMap (which implements IPersistentMap >>>>> but >>>>> extends? doesn't care) >>>>> >>>>> On Thu Jan 22 2015 at 5:28:30 PM Timothy Baldridge <tbald...@gmail.com> >>>>> wrote: >>>>> >>>> The logic of extends? is much simpler, so try that. IIRC it's something >>>>>> like "extends? returns true if any method on the protocol is implemented >>>>>> by >>>>>> x", "satisfies? returns true if all methods of a protocol are >>>>>> implemented >>>>>> by x". >>>>>> >>>>>> The docs don't seem to give much help here, so play with it in the >>>>>> repl a bit. >>>>>> >>>>>> Timothy >>>>>> >>>>>> On Thu, Jan 22, 2015 at 6:14 PM, Michael Blume <blume...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> (defprotocol my-protocol >>>>>>> (foo [this])) >>>>>>> >>>>>>> (extend-protocol my-protocol >>>>>>> clojure.lang.IPersistentMap >>>>>>> (foo [this] "hello from map")) >>>>>>> >>>>>>> (criterium.core/quick-bench >>>>>>> (satisfies? my-protocol {})) >>>>>>> >>>>>>> (criterium.core/quick-bench >>>>>>> (foo {})) >>>>>>> >>>>>>> Simply calling foo on an empty map takes 7 ns, >>>>>>> but checking whether the map satisfies my-protocol takes 22 µs, 3000 >>>>>>> times longer. >>>>>>> >>>>>>> It seems like to call foo, some mechanism has to look up an >>>>>>> implementation of my-protocol for maps -- how is it we can do that so >>>>>>> quickly for a call and so slowly for satisfies? >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Clojure" group. >>>>>>> >>>>>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. >>>>>> >>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> “One of the main causes of the fall of the Roman Empire was >>>>>> that–lacking zero–they had no way to indicate successful termination of >>>>>> their C programs.” >>>>>> (Robert Firth) >>>>>> >>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Clojure" group. >>>>>> >>>>> To post to this group, send email to clo...@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+u...@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+u...@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 clo...@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+u...@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+u...@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 clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> 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.
