And Happy April Fools' everyone. Nicely done Pradip.
On Tuesday, April 1, 2014 3:58:34 PM UTC-4, Jozef Wagner wrote: > > 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>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>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 >>>> 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. >>>> >>> >>> -- >>> 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.
