2015-06-24 1:25 GMT+02:00 Ben Wolfson <wolf...@gmail.com>:

> On Tue, Jun 23, 2015 at 4:17 PM, Ghadi Shayban <gshay...@gmail.com> wrote:
>
>>
>> Tangentially:
>> (remove even?)
>> Will be faster than
>> (remove (fn [i] (even? i)))
>> because in the first case the dereference of the var 'even?' happens only
>> once and the value inside the var will be passed to `remove` at the
>> outset.  In the second example the var dereference happens for every single
>> item (though it's very cheap).  The second example is equivalent to writing 
>> (remove
>> #'even?)
>>
>
> I can't seem to observe a difference between the two cases.
>

A simple var reference like even? compiles to a fetch of its root val:
@#'even?
In the first case, that happens only once, passing the resulting fn object
to remove. In the second case, the deref happens every time the fn is
called, thus allowing for redefinition of even?.

Have you ever passed passed #'handler to a server-start function (e.g. in a
ring app), so that you might redefine the handler fn during run time of the
server?

Ad. thread topic: As detailed, clojure's evaluation semantics already help
with transducers. Even better: Built transducer stacks should be pretty
accessible to the JIT, since they contain no more var references (in the
wiring). Also, since transducers are a kind of lexically closed pipe from
input effect to output effect, hotspot's escape analysis should also kick
in nicely.

-- 
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.

Reply via email to