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<javascript:> > > 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/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.
