range is reducible and boils down to just a local loop in most cases, so shouldn't create any heap garbage (well, other than whatever your reducing function does).
See: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LongRange.java#L229-L238 Additionally, it can act as a chunked lazy sequence, and in that usage it stores no values either, each chunk is just a start + a step and values are produced by offset. It does cache the lazy chunked sequence though, so you'll get a linked list of chunks essentially (representing 32 values each). More than you want to know can be found here: http://dev.clojure.org/jira/browse/CLJ-1515 Similar tricks are played with the other sequence "generators" like iterate, cycle, and repeat, although those don't chunk (http://dev.clojure.org/jira/browse/CLJ-1603). But to your original question about whether using sequences bloats memory - yes in the general case. For large sequences, you should consider alternatives - collections (like vectors) or in extreme cases Clojure primitive vectors (see vector-of), Java collections, or arrays (usually the most compact). Like everything else, sequences are a tradeoff, and generally a good one due to caching and immutability, tempered by chunking and transients. I'm glad we have more options now though with transducers. On Tuesday, May 10, 2016 at 7:21:12 PM UTC-5, tbc++ wrote: > > In addition, as of 1.7, (range 1000) no longer creates a lazy sequence. It > creates something that acts a bit like a sequence, but is reducable. So > doing something like (reduce + 0 (range 1000)) is super fast and creates > almost no garbage at all. > > On Tue, May 10, 2016 at 5:46 PM, Alan Thompson <clooj...@gmail.com> wrote: > >> I don't understand what you mean. '(range 1000)' produces a lazy >> sequence, and '(reduce + ...)' doesn't hold onto the head of the lazy >> sequence. Therefore, each element can be GC'd as soon as added into the >> running total, the the lazy sequence only produces new elements as they are >> requested by the reduction (chunking aside, of course). >> Alan >> >> On Tue, May 10, 2016 at 4:14 PM, JvJ <kfjwhee...@gmail.com> wrote: >> >>> That brings me to another thing I've wondered about. It is a typical >>> clojure idiom to do something like (reduce + (range 1000)). >>> >>> But, unlike imperative loops, this will cache all those 1000 elements. >>> This can kind of bloat memory, especially with large sequences? >>> >>> How can you get around it (other than tail-recursion or the while >>> construction)? >>> >>> On Tuesday, 10 May 2016 09:45:50 UTC-7, Alex Miller wrote: >>>> >>>> Because some of the time you don't want caching. For example, if you >>>> want to (later) reduce over a large (larger than memory even) external >>>> resource. eductions allow you to define the source in one spot but defer >>>> the (eager) reduction until later. >>>> >>>> On Tuesday, May 10, 2016 at 11:22:24 AM UTC-5, JvJ wrote: >>>>> >>>>> In that case, why aren't eductions just lazy sequences? >>>>> >>>>> On Monday, 9 May 2016 16:07:55 UTC-7, Alex Miller wrote: >>>>>> >>>>>> eductions are non-caching (will re-perform their work each time they >>>>>> are used), so most of the time I would say lazy sequences are preferable. >>>>>> >>>>>> On Monday, May 9, 2016 at 4:54:48 PM UTC-5, JvJ wrote: >>>>>>> >>>>>>> In a similar vein, do you think that eductions are generally a >>>>>>> better idea than lazy sequences/for comprehensions? >>>>>>> >>>>>>>> >>>>>>>> -- >>> 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. >>> >> >> -- >> 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. >> > > > > -- > “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.
