为什么Clojure的core.reducers比懒惰的收集函数更快

Question

在Reducers的许多资源（如the canonical blog post by Rich Hickey）中，声称reducer比常规的收集函数（(map ... (filter ...))等）要快，因为开销较少。

什么是避免的额外开销？ IIUC甚至懒惰的收集功能最终只走一次原始序列。计算中间结果的细节有何不同？

指针到Clojure中的实现，有助于理解上的差异将是最有帮助的太

Answer 1

我认为一个重要观点是，从original blog post下面这段话的一个：

(require '[clojure.core.reducers :as r]) 
(reduce + (r/filter even? (r/map inc [1 1 1 2]))) 
;=> 6 

这应该很熟悉 - 它是相同的命名函数，以相同的顺序应用，具有相同的参数，产生与Clojure基于seq的fns相同的结果。不同之处在于，减少渴望，并且这些减速器fns不在seq游戏中，没有每步分配开销，因此速度更快。当你需要时，懒惰是伟大的，但是当你不需要时，你不应该为此付出代价。

实现懒惰序列的带有一个（线性）分配成本：每从懒惰SEQ另一元件被实现，带seq的其余被存储在新的thunk时间，以及表示这样的'thunk'是a new clojure.lang.LazySeq object。

我相信这些LazySeq对象是引用中引用的分配开销。对于减速器，没有逐步实现惰性seq元素，因此根本没有实例化LazySeq thunk。

Answer 2

相关的地方“注意，有没有产生中间集合。”

这是改进，因为垃圾收集器的压力比较小。

当你结合像map,filter这样的操作时，那些函数迭代一个集合并返回一个新的集合，然后传递给下一个函数。减速器情况并非如此。

因此，它们可以用作那些功能（也就是说，它们以相同的方式组成）并且可以应用于相同的集合。但是增加了性能。

具有和不减速的地图/地图/过滤操作的粗糙和完全不科学草图如下：

没有减速器

初始集合=>地图=>中介集合=>地图=> intermediary collection => filter => final collection

没有reducer（即clojure.core map/filter函数）int中间集合是懒惰生产的。 也就是说，只有在下一个处理步骤需要时才产生新的元素，一次一个元素或一个块。

注意：块是由32个元素组成的块（尽管这应该被视为实现细节）。这是出于效率的原因，以避免从一次计算跳到另一次计算。

查看map函数return value例如：它返回lazy-seq（transducers的情况除外）。

随着减速

初步收集=>地图/地图/过滤器减速=>最终收集

如果您需要处理整个集合快，那么懒惰也是在越来越表现方式。删除懒惰seqs的中间层提供了性能增益。 Reducers可以做到这一点并且可以快速处理收集，因此速度更快。您还可以保持相同的功能来缓解切换。

请仔细阅读下面的意见，尤其是来自@米哈尔Marczyk