defrecord应高效实现IReduceInit

Question

在我们的TMD路径之一（来自Mastodon）中，我们使用defrecords来扩展数据集大小。令人惊讶的是，考虑到其他一切性能案例，实施IReduceInit实际上大大增加了计时。

tech.v3.dataset.reductions-test> (require '[criterium.core :as crit])
nil
tech.v3.dataset.reductions-test> (defrecord YMC [year-month ^long count]
  ;; clojure.lang.IReduceInit
  ;; (reduce [this rfn init]
  ;;   (let [init (reduced-> rfn init
  ;;                  (clojure.lang.MapEntry/create :year-month year-month)
  ;;                  (clojure.lang.MapEntry/create :count count))]
  ;;     (if (and __extmap (not (reduced? init)))
  ;;       (reduce rfn init __extmap)
  ;;       init)))
  )
tech.v3.dataset.reductions_test.YMC
tech.v3.dataset.reductions-test> (let [yc (YMC. :a 1)]
                                   (crit/quick-bench (reduce (fn [acc v] v) nil yc)))
Evaluation count : 6729522 in 6 samples of 1121587 calls.
             Execution time mean : 87.375170 ns
    Execution time std-deviation : 0.173728 ns
   Execution time lower quantile : 87.104982 ns ( 2.5%)
   Execution time upper quantile : 87.550708 ns (97.5%)
                   Overhead used : 2.017589 ns
nil
tech.v3.dataset.reductions-test> (defrecord YMC [year-month ^long count]
   clojure.lang.IReduceInit
   (reduce [this rfn init]
     (let [init (reduced-> rfn init
                    (clojure.lang.MapEntry/create :year-month year-month)
                    (clojure.lang.MapEntry/create :count count))]
       (if (and __extmap (not (reduced? init)))
         (reduce rfn init __extmap)
         init)))
  )
tech.v3.dataset.reductions_test.YMC
tech.v3.dataset.reductions-test> (let [yc (YMC. :a 1)]
                                   (crit/quick-bench (reduce (fn [acc v] v) nil yc)))
Evaluation count : 43415358 in 6 samples of 7235893 calls.
             Execution time mean : 11.775423 ns
    Execution time std-deviation : 0.197683 ns
   Execution time lower quantile : 11.594695 ns ( 2.5%)
   Execution time upper quantile : 12.079668 ns (97.5%)
                   Overhead used : 2.017589 ns
nil
tech.v3.dataset.reductions-test> (defmacro reduced->
  [rfn acc & data]
  (reduce (fn [expr next-val]
            `(let [val# ~expr]
               (if (reduced? val#)
                 val#
                 (~rfn val# ~next-val))))
          acc
          data))

#'tech.v3.dataset.reductions-test/reduced->
tech.v3.dataset.reductions-test> 

与其他成员讨论后，似乎在__extmap不为nil的情况下（它使用clojure.core/get而不是直接调用getorDefault），值查找路径也可以进行优化。

• https://github.com/techascent/tech.ml.dataset/blob/master/test/tech/v3/dataset/reductions_test.clj#L197

Answer 1

这很有趣。我实际上在1.12.0-alpha1的其他reduce更改的背景下看过这个问题，但我们没有证据表明它是问题。我明天会为此创建一个工单。

Comments

有趣！我也花费了大量时间，用强行和 dtype-next 来使 reduce 尽可能快。我在几乎所有可能的情况下都对其进行了大量性能分析，并解决了一些细节问题，例如使 map 和 filter 操作（及 transducers）尊重 map 函数或 filter 函数的运行时类型，这样你就可以构造原始类型操作的链，而整个链将是原始类型，中间没有装箱。

这是一个奇怪的巧合，有些研究意味。

Answer 2

记录在https://clojure.atlassian.net/browse/CLJ-2750