函数文件夹和减少器对nil和数组类型损坏，以及错别字的修复

Question

1. 目前不起作用

(->> nil

 (r/map identity)
 (r/reduce + 0))
 ; org.mozilla.javascript.JavaScriptException: Error: No protocol method IReduce.-reduce defined for type null

这种情况的原因是，由r/reducer或r/folder创建的减少器直接调用-减少（of IReduce）。因此，它们绕过了函数r/reduce中nil的特殊情况。

1. 对于数组类型的集合也存在一个完全类似的问题。

2. 补丁CLJS-700错误地将coll-fold定义为类型cljs.core/IPersistentVector。这应该是cljs.core/PersistentVector。（在ClojureScript中不存在协议IPersistentVector。）

我很快将附上一个补丁，该补丁通过实现IReduce对nil和array来解决上述所有问题。该补丁还包括单元测试。

Answer 1

评论者：jdevuyst

另一个补丁，其中r/reduce和r/fold将数组和nil作为特殊情况处理 -- 相比之下，数组和nil实现了IReduce和CollFold。

r/reducer、r/folder和r/Cat的协议方法现在调用r/reduce和r/fold，而不是直接调用-reduce和coll-fold。

该补丁还修复了Cat中coll-fold实现的错误，该实现之前使用(reducef)而不是(combinef)作为初始值。新代码直接从Clojure实现复制，并使用fork-join占位符。

Answer 2

_评论者：dnolen_

第二个补丁中的{{implements?}}可能应该是{{satisfies?}}。您对补丁前后运行过任何基准测试吗？

Answer 3

_由：jdevuyst_ 评论：

如果我理解正确的话，那么 {{(satisfies? x y)}} 大约等同于 {{(or (implements? x y) (natively-satisfies? x y))}}。

如果原生的类型（当前为 nil、数组、对象）被视为特殊情况，那么 {{implements?}} 看起来更合适。

然而，{{satisfies?}} 也起作用，因此我附上了一个新的 'alt' 补丁。

Answer 4

评论者：jdevuyst

第一个补丁在运行以下代码时实际上更快

(time (->> (repeat 1000 (vec (range 1000)))
           vec
           (r/mapcat identity)
           (r/map inc)
           (r/filter even?)
           (r/fold +)))

这大约需要 700 毫秒。使用第一个补丁可以快 100-300 毫秒。这是在反复（但非正式）测试之后的结果。

我想担心的可能是第一个补丁可能会减慢其他随机代码，因为它涉及到扩展 nil、数组和对象类型。我不确定我到底应该测试什么。

（注意，第二个和第三个补丁也包含对 {{Cat}} 的修复，并包含了更多的单元测试。建议不要直接应用第一个补丁。）

Answer 5

由：dnolen 评论：

是的，你测试了太多东西，包括 {{vec}}、{{range}}、延迟序列。也测试了小 N。看看 Mori README 上的 reducers 示例 - https://github.com/swannodette/mori。谢谢。

Answer 6

_由：jdevuyst_ 评论：

我尝试运行以下代码


(let [coll (vec (repeat 1000 (vec (range 10))))]
  (time (doseq [n (range 1000)]
               (->> coll
                    (r/mapcat identity)
                    (r/map inc)
                    (r/filter even?)
                    (r/fold +)))))


我得到的一些最后结果如下

第一个补丁：75680 毫秒
第二个补丁：76585 毫秒

说真的，尽管第一个补丁似乎大多数时候都赢，但有时第二个补丁更快。

我还尝试了一件事，即将第二个补丁中的{{implements?}}/{{satisfies?}}检查删除，并覆盖类型{{object}}的协议方法coll-fold，而不是像第一个补丁那样做（与第一个补丁类似）。这种“混合”方法通常会导致（但不总是）性能下降。

我不确定该如何进行。我或许可以同时运行这两个补丁几分钟？

Answer 7

由：dnolen 评论：

这仍然不是一种好的计时方式，您在记录范围的成本和seq'ing。请使用{{dotimes}}。

Answer 8

评论者：jdevuyst

嗯。我想这种拖延的序列确实导致了很多分配。

好的，我重写了测试并用它运行了几次。现在我还在向量和数组上进行了测试。

补丁1需要稍作调整。当调用coll-fold时，补丁1只为类型{{object}}指定了回退（即调用r/reduce）。我必须添加相同类型{{array}}的回退。（这很奇怪！）

所以以下是结果。

对于向量

`
(let [coll (vec (repeat 100 (vec (range 100))))]
(time (dotimes [n 3000]

      (->> coll
          (r/mapcat identity)
          (r/map inc)
          (r/filter even?)
          (r/fold +)))))

`

补丁1：205872毫秒
补丁2：210756毫秒

对于数组

`
(let [coll (into-array (repeat 100 (into-array (range 100))))]
(time (dotimes [n 3000]

      (->> coll
          (r/mapcat identity)
          (r/map inc)
          (r/filter even?)
          (r/fold +)))))

`

补丁1：123567毫秒
补丁2：119704毫秒

我多次运行测试，结果相当一致。补丁1对向量更快，补丁2对数组更快。

这很有道理。

在补丁1中，{{reducer}}将直接调用{{-reduce}}。在补丁2中，{{reducer}}首先调用{{r/reduce}}，如果集合是向量则调用{{-reduce}}，如果是数组则调用{{array-reduce}}。因此，补丁2在向量的情况下多了一个函数调用，但在数组的情况下避免了在本地类型上调用协议方法。

使用宏（或复制粘贴）可以避免额外的函数调用。这值得一试吗，或者保持代码干净更重要？

--

我刚刚意识到补丁2在语义上与Clojure略有不同，尽管这可能是在Clojure中的一个错误：https://groups.google.com/forum/#!searchin/clojure-dev/kv-reduce/clojure-dev/bEqECvbExGo/iW4B2vEUh8sJ。我建议使用宏（或复制粘贴）以避免补丁2中的额外函数调用，这也可以解决这个差异。

Answer 9

由：dnolen 评论：

你是如何进行基准测试的？使用V8？JavaScriptCore？SpiderMonkey？在浏览器中？什么优化设置等。

Answer 10

评论者：jdevuyst

我使用了 repljs（Rhino？）。我将在明天的更具现实性的环境中再次测试。

Answer 11

由：dnolen 评论：

是的，使用 Rhino 进行基准测试并不具有信息性。

Answer 12

评论者：jdevuyst

我使用 cljs 编译了相同的代码（n=3000）。

然后我在 Firefox、Chrome 和 Safari 最新稳定版本中进行了测试。我关闭了我的所有浏览器。对于每个浏览器，我遵循以下程序

• 打开浏览器
• 打开开发者控制台
• 运行补丁 1 的基准测试
• 运行补丁 2 的基准测试
• 运行补丁 1 的基准测试并记录结果
• 运行补丁 2 的基准测试并记录结果
• 关闭浏览器

Firefox
- 补丁 1。向量：26057 毫秒
- 补丁 1。数组：25026 毫秒
- 补丁 2。向量：26258 毫秒
- 补丁 2。数组：36653 毫秒
- 总结：补丁 1 在向量和数组上更快

Chrome
- 补丁 1。向量：7804 毫秒
- 补丁 1。数组：7092 毫秒
- 补丁 2。向量：7754 毫秒
- 补丁 2。数组：6768 毫秒
- 总结：补丁 2 在向量和数组上更快

Safari
- 补丁 1。向量：167230 毫秒
- 补丁 1。数组：108780 毫秒
- 补丁 2。向量：173940 毫秒
- 补丁 2。数组：110012 毫秒
- 总结：补丁 1 在向量和数组上更快

我不知道该如何处理这些问题。

Answer 13

评论者：jdevuyst

我附上了第一个补丁的新版本。

此补丁修复了与 {{r/Cat}} 相关的问题。（这个问题也在第二个和第三个补丁中得到了解决。包括一个单元测试。）

此补丁还修复了数组中的 {{r/fold}}。

总结来说，需要在以下补丁之间做出选择。

• CLJS-736-patch-1-redux.patch
• CLJS-736-alt.patch（使用 implements？）/ CLJS-alt-satisfies.patch（使用 satisfies？）

如上所述，alt 补丁在精神上与 Clojure 源代码略有不同。alt 补丁在精神上更接近于 ClojureScript 源代码。

如上所述，alt 补丁在语义上与原始 Clojure 源代码略有不同，但尚不清楚哪种行为是“正确的”。

Answer 14

由：dnolen 评论：

如果基准测试能够解释修补程序前后性能的变化，将更有信息量。

Answer 15

评论者：jdevuyst

{{r/reduce}} 之前对 nil 或 JavaScript 数组不起作用。

我难以推荐修补程序的一个原因是我不了解您想优化什么用例。