将三重arity添加到 < <= > >= = == not=

Question

在我的实践中，使用小于/大于运算符的三重arity相当常见，例如检查一个数字是否在范围内


(< 0 temp 100)


问题在于，它比{{(and (< 0 temp) (< temp 100))}}慢近三倍。

这是因为三重arity由通用的vararg arity分支处理


(defn <
  "如果数字按单调递增顺序排列，则返回非nil值，否则返回false。"
  {:inline (fn [x y] `(. clojure.lang.Numbers (lt ~x ~y)))
   :inline-arities #{2}
   :added "1.0"}
  ([x] true)
  ([x y] (. clojure.lang.Numbers (lt x y)))
  ([x y & more]
    (if (< x y)
       (if (next more)
         (recur y (first more) (next more))
       (< y (first more)))
      false)
    false)


此补丁为以下函数添加了针对三重arity的特殊处理：{{< <= > >= = == not=}}


(defn <
  "如果数字按单调递增顺序排列，则返回非nil值，否则返回false。"
  {:inline (fn [x y] `(. clojure.lang.Numbers (lt ~x ~y)))
   :inline-arities #{2}
   :added "1.0"}
  ([x] true)
  ([x y] (. clojure.lang.Numbers (lt x y)))
  ([x y & more]
  ([x y z] (and (. clojure.lang.Numbers (lt x y))
                (. clojure.lang.Numbers (lt y z))))
  ([x y z & more]
   (if (< x y)
     (let [nmore (next more)]
       (if nmore
         (recur y z (first more) nmore)
         (< y z (first more))))
     false)))


性能提升相当显著


(= 5 5 5)      24.508635 ns => 4.802783 ns (-80%)
(not= 1 2 3)      122.085793 ns => 21.828776 ns (-82%)
(< 1 2 3)      30.842993 ns >> 6.714757 ns (-78%)
(<= 1 2 2)      30.712399 ns => 6.011326 ns (-80%)
(> 3 2 1)      22.577751 ns => 6.893885 ns (-69%)
(>= 3 2 2)      21.593219 ns => 6.233540 ns (-71%)
(== 5 5 5)      19.700540 ns => 6.066265 ns (-69%)


更高阶arity也变快了，主要是因为现在迭代次数减少了


(= 5 5 5 5)      50.264580 ns => 31.361655 ns (-37%)
(< 1 2 3 4)      68.059758 ns => 43.684409 ns (-35%)
(<= 1 2 2 4)      65.653826 ns => 45.194730 ns (-31%)
(> 3 2 1 0)      119.239733 ns => 44.305519 ns (-62%)
(>= 3 2 2 0)      65.738453 ns => 44.037442 ns (-33%)
(== 5 5 5 5)      50.773521 ns => 33.725097 ns (-33%)


此外，此补丁还将{{not=}}的vararg arity更改为使用next/recur而不是{{apply}}


(defn not=
  "与(not (= obj1 obj2))相同。"
  {:tag Boolean
   :added "1.0"
   :static true}
  ([x] false)
  ([x y] (not (= x y)))
  ([x y z] (not (= x y z)))
  ([x y z & more]
   (if (= x y)
     (let [nmore (next more)]
       (if nmore
         (recur y z (first more) nmore)
                   (not= y z (first more))))
     true)))


结果良好


(not= 1 2 3 4)      130.517439 ns => 29.675640 ns (-77%)


我也在 BLJ-1912 中做了类似的操作（只计算一次 {{(next more)}}），尽管仅此一项的性能提升并不大。

我的观点是，优化三个参数的情况是有意义的，因为它们在真实代码中出现的频率相当高。更高参数（4个或更多）的使用则少得多。

Answer 1

评论由：tonsky 发布

基准测试代码在此 https://gist.github.com/tonsky/442eda3ba6aa4a71fd67883bb3f61d99

Answer 2

评论由：alexmiller 发布

将此与 CLJ-1912 结合可能会有更多的意义，否则这些补丁可能会相互冲突。

Answer 3

评论由：tonsky 发布

如果首先应用 CLJ-1912，请使用此补丁

Answer 4

评论由：tonsky 发布

我发现在之前的一些补丁中，在定义 {{=}}（等于）时，{{and}}（和）还未定义。用 {{if}} 替换。

Answer 5

评论由：alexmiller 发布

与 CLJ-1912 重复

Answer 6

评论者：tonsky

[~alexmiller] 这是一个重复项，但我的补丁要快得多。只需看看这些数字（70-80%的改进，而原来是5-10%）。因为我在这里引入了一个真正的arity，所以中间集合不会被创建，在有三个参数的情况下也不会被解构。

Answer 7

评论者：wagjo

提供的补丁中有一个相当严重的错误，这导致例如 {{(= 3 3 2)}} 返回true。因此，我想这个基准也可能不正确。

Answer 8

评论者：tonsky

[~wagjo] 谢谢你找到这个问题！附上一个更新的路径。由于性能提升并不是来自做更少的/更多的比较，而是不需要调用未知arity的函数的额外开销，所以基准测试也没有太大的错误。

Answer 9

参考： https://clojure.atlassian.net/browse/CLJ-2075（由tonsky报告）