The problem is the reversing of the list if you want to convert back to a list. You can avoid this but you have to use a custom mapping operation, continuation passing style, and a trampoline - it won't be fast.
Another option is to realize that concrete types simply don't matter. What you're trying to avoid is getting stuck with a ISeq vs. a IPersistentList (note you shouldn't care about having a PersistentList as none of the Clojure fns target that). One bit of cleverness you could do is to create a new type that satisfies all the interfaces of IPersistentList and return that instead (under the hood you can hide the lazy sequence or whatever you like generated by the mapping operation). A bit more work but probably accomplishes what you want. David On Fri, Jun 21, 2013 at 9:32 AM, Jim - FooBar(); <jimpil1...@gmail.com>wrote: > On 21/06/13 14:08, Philip Potter wrote: > > Your logic here is incorrect. To say "transients == fast, persistents > == slow" is to grossly oversimplify things. > > > Yes, I am indeed oversimplifying things but that doesn't change the fact > that 'into' will be *slower* for collections that don't have transient > cousins than the ones that have. It will also be slower if you don't use > the 'transient-capabilities' than when you use them. I didn't mean to say > that persistents==slow but rather that filling up a transient will always > be faster (for more than 5-6 elements I') than filling up a persistent. > > The default data structures are **fast**. Transients are offered, where > they make sense, as optimization to make things go **faster**. Note that > this does not change the big-O complexity. > > I did not imply otherwise did I? > > There is no analogous case in lists. Every conj operation necessarly > allocates a new cons cell; there is no scope for saving time by > bashing in place. Therefore, there is no transient for lists. > > The fact that no transient optimization exists for lists does not mean > that lists are slow. This logic simply does not follow. > > > again, I never said that lists are slow but that with my current > implementation the extension-point for IPeristentList is consistently > slower than all the rest extensions. Even lazy-seqs are faster (NOT the > data-structure but the mapping operation). Therefore I'd like to get it > in-par with at least lazy-seqs. > > > If you're afraid of performing 2 passes, you could take advantage of > laziness: > > (->> (rseq v) > (map f) > (into '())) > > Since map is lazy, this will only perform one pass (though it appears > on first glance that it performs two). > > > I already tried that but cannot call 'rseq' on a PersistenList and reverse > would do an entire pass. > ClassCastException clojure.lang.PersistentList cannot be cast to > clojure.lang.Reversible clojure.core/rseq (core.clj:1497) > > > > but I would be wary of your use of the word "fastest" at the top. > Normally on the JVM, the answer to a "what is the fastest way to..?" > question is "it depends". A much easier question to answer is "Is X > fast enough?" > > > I thought I was very careful to provide all the details for the "what does > it depend on?" question. Ok, the title just reads "fastest way..." but in > the message I explained all the constraints of my problem. I carefully > said "the fastest way to produce a list from mapping" and since I explained > that these are all protocol extensions you can infer that I am extending it > to PersistenLIsts and I want to produce PersistentLists. The question is > much narrower now isn't it? in any case I apologise for potentially causing > confusion... this wasn't even a question about performance...I don't care > if the fastest way is fast enough. All I care is that I find the fastest > way...if that's not fast-enough then the consumer can choose not to use > it...but I do want to offer the fastest way to do it by default (should the > user choose it)...much like 'conj' works polymorphically > > regards, > > Jim > > > > > > -- > -- > 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. > > > -- -- 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.
