I would say transducers are preferable when: 1) you have reducible collections 2) you have a lot of pipelined transformations (transducers handle these in one pass with no intermediate data) 3) the number of elements is "large" (this amplifies the memory and perf savings from #2) 4) you put to produce a concrete output collection (seqs need an extra step to pour the seq into a collection; transducers can create it directly) 5) you want a reusable transformation that can be used in multiple contexts (reduction, sequence, core.async, etc)
On Monday, November 27, 2017 at 8:33:50 PM UTC-6, Jiacai Liu wrote: > > > Also, most of the performance boost from transducers is due to less > garbage being created, and some times the heap of the JVM is so large > you'll never see much change from switching to transducers. > > Thanks for this tip. I seldom use transducers in my daily work, and I was > convinced transducers are a better choice in whatever situation after > reading some articles. But the test shows it isn't an easy choice, only > when do something reducible, will transducers make more sense. > > On Tuesday, November 28, 2017 at 5:07:10 AM UTC+8, tbc++ wrote: >> >> >> Also, I think the transducer version should always be faster, no >> matter the size of the source collection (no threshold). >> >> It's a bit more complicated than that, mostly because transducer >> pipelines require about 2 allocations per step during creation. Also, most >> of the performance boost from transducers is due to less garbage being >> created, and some times the heap of the JVM is so large you'll never see >> much change from switching to transducers. >> >> Don't get me wrong, transducers are great and I often default to them >> over seqs, but in micro-benchmarks like this there's too much in play to >> always see a 100% performance boost. >> >> On Mon, Nov 27, 2017 at 12:55 PM, David Bürgin <dbue...@gluet.ch> wrote: >> >>> Jiacai – >>> >>> I saw you updated the gist. Just in case it passed you by: performance >>> profits from the source collection being reducible. So pouring ‘dataset’ >>> into a vector beforehand should speed up the processing quite a bit. >>> >>> Also, I think the transducer version should always be faster, no matter >>> the size of the source collection (no threshold). >>> >>> >>> -- >>> David >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> “One of the main causes of the fall of the Roman Empire was that–lacking >> zero–they had no way to indicate successful termination of their C >> programs.” >> (Robert Firth) >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
