使用core.reducers时的性能提升
使用core.reducers时的性能提升
提问于 2019-08-08 03:11:32
我尝试了下面的方法来比较core/map vc core.reducers/map vs core.reducers/fold的性能-
(time (->> (range 10000)
(r/map inc)
(r/map inc)
(r/map inc)
(into [])))
;; core.reducers/map
;; "Elapsed time: 3.962802 msecs"
(time (->> (range 10000)
vec
(r/map inc)
(r/map inc)
(r/map inc)
(r/fold conj)))
;; core.reducers/fold
;; "Elapsed time: 3.318809 msecs"
(time (->> (range 10000)
(map inc)
(map inc)
(map inc)))
;; core/map
;; "Elapsed time: 0.148433 msecs"
(time (->> (range 10000)
(sequence (comp (map inc)
(map inc)
(map inc)))))
;; transducers
;; "Elapsed time: 0.215037 msecs"1)我的期望是core/map的时间最长，但是它的时间最短。当没有为传感器创建中间序列时，为什么它比传感器性能更好，而且传感器应该更快？
2)为什么core.reducers/fold版本没有明显快于core.reducers/map版本，它不应该并行化操作吗？
3)为什么core.reducers版本比懒惰的版本慢，整个序列都是在最后实现的，那么急切的评估不应该比懒惰的版本性能更好吗？
回答 1
Stack Overflow用户
发布于 2019-08-08 03:15:18
核心
- 映射是惰性的，所以您使用核心/映射的测试用例根本不起作用。尝试在集合中使用
doall(或into [])，我希望它终究会是最慢的。你可以通过将10000改为1e12来说服自己，并观察到，如果你的计算机可以处理一万亿个元素，就像它可以处理一万个元素一样快，那么它肯定不会为每个元素做太多工作！
- ，有什么可以并行化的？这个操作最昂贵的部分不是对
inc的调用(是并行化的)，而是将结果组合到最后的一个向量中(这是不可能的)。尝试使用更昂贵的函数，如#(do (Thread/sleep 500) (inc %))，您可能会看到不同的结果。
- 这不是和(1)相同的问题吗？
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/57400918
复制相关文章
相似问题