Re: is reduce/reduced faster than loop/recur?

And just to add a pointer in case anybody's interested in opting in to this behaviour in a custom type, it's possible to do so by implementing clojure.core.protocols/IKVReduce (data.avl does this) or clojure.lang.IKVReduce (the iface implemented by built-in maps; clojure.core provides

Re: is reduce/reduced faster than loop/recur?

Yes, and it happens for most collections. Vectors, maps, etc. There's even a fast path for reduce-kv on maps that doesn't create key value entry objects. Timothy On Fri, Apr 29, 2016 at 6:06 PM, Mark Engelberg wrote: > So you're saying that this is an optimization

Re: is reduce/reduced faster than loop/recur?

So you're saying that this is an optimization that is automatically called when you invoke Clojure's standard reduce function on something like a vector? On Fri, Apr 29, 2016 at 1:14 PM, Alex Miller wrote: > The main internal protocol is really CollReduce for collections

Re: is reduce/reduced faster than loop/recur?

The main internal protocol is really CollReduce for collections that can reduce themselves. InternalReduce is for concrete seq implementations that can reduce themselves. For cases where you are creating new things, you can also plug in a little more easily by implementing the IReduceInit

Re: is reduce/reduced faster than loop/recur?

puzzler, No, Clojure actually has quite a lot of protocols for reducing "things". But they are so many that I got lost in which does what and how, so I wanted a clarification on the subject. Alex miller, excellent answer already gave me some overview of the topic. Here is a link to Clojure's

Re: is reduce/reduced faster than loop/recur?

By "internal reduce", are you all talking about the Clojure reducers library, or something else? -- 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

Re: is reduce/reduced faster than loop/recur?

Both loop/recur and reduction/transduce via IReduce are similar in doing looping without consuming stack, building up an accumulated value, and not allocating memory. reduce/transduce always take an input collection - if that collection can be traversed via internal reduction or sequential

Re: is reduce/reduced faster than loop/recur?

hey Jozef, would you mind sharing a blog post or piece of documentation where I can learn about those strategies? The only one that I know so far is the local primitives for fast arithmetic, but besides from that I haven't heard of any ther optimization for loop/recur strategy :/ El

Re: is reduce/reduced faster than loop/recur?

There are many ways on how you can improve the performance of loop/recur, and most of them depends on the type of a thing you are iterating through. With reducers (and transducers), the iteration part is decoupled from the reduction part, so they offer a mechanism that chooses the optimal

is reduce/reduced faster than loop/recur?

I have been hearing a lot of Clojure's use of an internalReduce protocol, which seems to speed up things when using reduce. Now the thing is that a lot of people also claim that tail-call-recursion is also pretty fast, which lets me wondering: - if I could replace a loop/recur with an