3 ms·
Something I found interesting when playing with the example code is that, while folding in parallel certainly speeds up the execution for realized sequences, it
by piercebot 9y ago
Something I found interesting when playing with the example code is that, while folding in parallel certainly speeds up the execution for realized sequences, it may not make sense to realize a sequence that you're only going to use for one operation:
user=> (require '[clojure.core.reducers :as r])
user=> (def s (range 9999999))
user=> (time (r/fold + (r/map inc (r/filter even? s))))
"Elapsed time: 450.318641 msecs"
25000000000000
user=> (time (r/fold + (r/map inc (r/filter even? (vec s)))))
"Elapsed time: 463.632907 msecs"
25000000000000
Note the `(vec s)` instead of just `s` in the second timed run above
user=> (def sv (vec s))
user=> (time (r/fold + (r/map inc (r/filter even? sv))))
"Elapsed time: 156.731683 msecs"
25000000000000
Far from a ~3x speedup (in these contrived examples), realizing the sequence in-line yields approximately the same performance as if it was operated on lazily.
Something to keep in mind if you're trying to optimize your Clojure. This is still the best resource I've read on reducers/transducers :)
[edit: code formatting]
- wellpast 9y agoThe performance disparity is even more dramatic on my machine. What's the reason for that - is it b/c of concurrent contention during vec/realization? Or ???
- wellpast 9y agoFor posterity, I just answered my own Q. Performance overhead was just the cost of the linear cost of vec realization as you pointed out. At first it seemed like I was seeing additional overhead.