(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 whe
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 re
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
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 pro
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, sat
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
> fa
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 wrote:
> Clojure isn't doing the caching. The JVM is doing the caching. In this
> case, Clojure just has mechanical sympathy for how the
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, where
Ghadi Shayban writes:
> 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 covera
Tassilo Horn writes:
>> 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 cove
phillip.l...@newcastle.ac.uk (Phillip Lord) writes:
>> I use satisfies? for optional features, e.g., if some data structure
>> satisfies some protocol, then that optional feature is enabled, else
>> it's disabled. But that's not really on a hot path so I don't care
>> much about satisfies? perfor
On Friday, January 23, 2015 at 3:13:08 PM UTC-5, Tassilo Horn wrote:
>
> philli...@newcastle.ac.uk (Phillip Lord) writes:
>
> >> I use satisfies? for optional features, e.g., if some data structure
> >> satisfies some protocol, then that optional feature is enabled, else
> >> it's disabled. Bu
Fluid Dynamics writes:
Hi!
> One approach is to have a first-class-edges? method in the mother
> graph protocol. Another is to have such a method in IEdges and extend
> that to Object with first-class-edges? returning false and the other
> IEdges-specific methods throwing IllegalStateExceptions
13 matches
Mail list logo
