Reducers should be given IMO a more attention, support and importance and I'm actually experimenting on a hypothesis that reducers can replace lazy seqs in most cases (excluding simple stuff, e.g. destructuring). Imagine a core API where functions like map, filter, rseq, range etc. are working with reducers by default and falling back to seqs only in rare cases or by explicit request.
Jozef On Tuesday, April 1, 2014 9:28:49 PM UTC+2, tbc++ wrote: > > The question is "replace them with what"? I remember with not so fond > memories the days of using IEnumerable in C#, there was no immutability and > no caching. So if you created a massive chain of data and iterated over it > twice you would have to execute the entire chain of functions twice. With > LazySeqs the data would be evaluated once and the final result stored for > each iterator. > > It's a trade off, but I'm constantly amazed at how wickedly fast LazySeqs > are. > > Also, reducers are a good option when LazySeqs aren't fast enough. > > Timothy > > > On Tue, Apr 1, 2014 at 1:17 PM, Andy Fingerhut > <andy.fi...@gmail.com<javascript:> > > wrote: > >> Back of the envelope meaning that you thought about the implementation >> and are estimating, or you have measurements? >> >> Either way, I agree that there are definitely use cases where non-lazy >> processing can give performance improvements. Probably even relatively >> common use cases. >> >> Cases where lazy sequences have advantages (not intended to be an >> exhaustive list): >> >> + if you determine that you do not need the whole sequence, portions of >> it need not be generated at all (perhaps large portions) >> >> + I do not have measurements for this use case to quantify the potential >> performance benefits, but if you have a 'pipeline' of lazy operations, e.g. >> a map on function f1 whose result is fed into a map on function f2, then a >> filter on function f3, etc., the time order of execution will typically >> have f1 called on an item in the sequence, then f2, then f3, etc., and only >> after that is done will you go back and call f1, f2, f3, ... on the next >> item of the original sequence. There can be performance benefits from >> keeping those intermediate results in a processor's cache while doing f1, >> f2, f3, etc., rather than a whole pass of applying f1, then going back to >> the beginning and doing a whole pass of f2, etc. This is primarily an >> issue with sequences that are large enough that they do not fit into the >> cache. >> >> Andy >> >> >> >> On Tue, Apr 1, 2014 at 11:19 AM, Pradip Caulagi >> <pra...@wwstay.com<javascript:> >> > wrote: >> >>> I am just a newbie who has been hanging around and it is rather late in >>> the day to bring this up but... >>> >>> should we remove lazy sequences and lazy evaluation from Clojure? Back >>> of the envelope calculations show that we can get 2x performance >>> improvements. >>> >>> Thanks, >>> Pradip >>> >>> -- >>> 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<javascript:> >>> 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 <javascript:> >>> 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 <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> 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<javascript:> >> 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 <javascript:> >> 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 <javascript:>. >> 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.
