I was not trying to generalize. I think that ISeq is not the right tool in case where processing of large collection is a performance bottleneck. It is perfectly OK for other purposes though.
Cons cell has its next object 'recorded', however this next object does not have to be Cons, in which case calling next on it will create a new object. LazySeq (a type) is just a delay with fancy interface, and it just emphasizes ISeq's perf issues. Moreover, the fact that you usually do not want to hold onto the head in a lazy seq (a virtual collection [1]) indicates that the caching of 'next' is not what you want when iterating over large data. The performance issues in ISeq led to the design of chunked seqs [2] and reducers, both of which try to eliminate this "per-step allocation overhead" [3]. An expensive collection crunching should not be based just on the ISeq abstraction. Best, Jozef [1] http://clojure.org/lazy [2] https://www.assembla.com/spaces/clojure/wiki/Chunked_Seqs [3] http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html On Mon, Mar 3, 2014 at 5:35 PM, Mikera <mike.r.anderson...@gmail.com> wrote: > On Monday, 3 March 2014 18:24:48 UTC+8, Jozef Wagner wrote: >> >> >> On Mon, Mar 3, 2014 at 3:06 AM, Mikera <mike.r.an...@gmail.com> wrote: >> >>> ISeq itself isn't too bad (it's just an interface, as above), but some >>> of the implementations are a bit expensive. >>> >> >> ISeq is inherently not suited for performance critical code, as next() >> requires creation of a new object. Even if JVM handles such ephermal >> instances quite well, it still cannot compete with simple iterations or >> mutable iterators. >> > > That isn't true in general: cons cells for example already have the next > object recorded so don't cause an allocation on next(). And lazy seqs only > cause an allocation on the first invocation next(). Given this, ISeq is a > perfectly decent way to traverse singly linked links, which is in turn a > good data structure for many use cases. It's probably even optimal in many > tree-like cases where a lot of structural sharing is possible. > > Obviously, there are cases where allocating a sequence will be slower than > iterative techniques. But that's easy enough to fix by just using > iterations in those cases.... use the right tool for the job and all that. > > Overall - I think ISeq is perfectly decent for what it does. > > -- > 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/groEven for linked lists, as they are swiftly > transformed into something more sinister after few map/filter/reduce > operations.up/clojure?hl=en <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/groups/opt_out. > -- 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/groups/opt_out.
