2024 Clojure状态调查中分享您的看法!

欢迎!请访问关于页面了解更多该网站的工作方式。

0
Clojure
在我的实践中,使用小于/大于操作的三价形式很常见,例如检查一个数字是否在范围内。


(< 0 temp 100)


问题是,它比 {{(and (< 0 temp) (< temp 100))}} 慢了近三倍。

这是因为三价形式由通用可变数量参数形式分支处理。


(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)


这个补丁为这些函数添加了三价参数的特殊处理:{{< <= > >= = == 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%)


更高的阶数也更加快速,主要是因为现在迭代次数更少。


(= 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 纳秒 => 33.725097 纳秒 (-33%)


此补丁还修改了{{not=}}的变长参数形式,使用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 纳秒 => 29.675640 纳秒 (-77%)


我在这里想要指出,优化三个参数的函数是有意义的,因为它们在真实代码中出现的频率很高。参数更多的(4个及以上)函数出现的频率要低得多。

9回答

0
通过

评论由:tonsky撰写

基准代码在这里https://gist.github.com/tonsky/442eda3ba6aa4a71fd67883bb3f61d99

0
通过

评论由:alexmiller撰写

将其与 CLJ-1912 合并可能更有意义,否则这些补丁可能会相互冲突。

0
通过

评论由:tonsky撰写

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

0
通过

评论由:tonsky撰写

我发现了之前补丁的一个问题,在定义{{=}}(相等性)时,{{and}}(且)尚未定义。用{{if}}替换了它。

0

评论由:alexmiller撰写

与CLJ-1912重复

0
评论者:tonsky

[~alexmiller] 这是一个重复,但我的补丁要快得多。只需看看数字(70-80%的提升,与5-10%相比)。这是因为我引入了真正的arity,所以中间的集合不会创建,也不会在有三个参数的情况下进行解构。
0

评论者:wagjo

提供的补丁(们)存在一个相当严重的错误,导致例如{{(= 3 3 2)}}返回true。因此,我猜想基准测试也存在问题。

0
评论者:tonsky

[~wagjo] 谢谢你指出这个问题!附上一个更新的路径。基准测试并没有很大幅度地存在问题,因为性能提升并不是通过做一次更少的/更多比较,而是因为没有调用一个未知arity的函数的开销。
0
参考:[~tonsky](https://clojure.atlassian.net/browse/CLJ-2075)
...