>>> lookup (find-protocol-method) over the method invocation itself. Is that the
>>> right way to summarize the performance implications?
>>
>> No, since the result is cached. The real every-call overhead is having to
>> go through the var to detect changes to the protocol, vs the inline-defined
>> case where the implementation of the interface can't change given the same
>> instance class.
>
> Am I saying something different? The cache requires a hash lookup, right?
I thought the eventual goal was to implement call-site caching in
bytecode? Inline caching isn't feasible due to the direct and indirect
cost of regenerating bytecode. But you can still do non-inline
caching! For the simplest and highest payoff case of monomorphism, it
would look something like this:
(protocol-function x ...)
=>
(let [cache# <atom created at compile time>]
(if (= (:expected-type @cache#) (type x))
((:expected-function @cache#) x ...) ;; hit
(let [actual-function <look up protocol-function in (type x) the
hard way>] ;; miss
(swap! cache# (constantly {:expected-type (type x),
:expected-function actual-function}))
(actual-function x ...))))
It occurs to me that you could even pull off this code transformation
entirely in-language with CL-style compiler macros while leaving alone
references to protocol-function in non-operator position.
-Per
--
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
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
