<div dir="ltr">No one should rely on eq? of lists..... especially not in code that didn't exist in the pre-immutable cons days.</div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Feb 11, 2013 at 12:17 PM, Neil Toronto <<a href="mailto:neil.toronto@gmail.com" target="_blank">neil.toronto@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The performance of `sequence->list' came up on this thread: <a href="http://thread.gmane.org/gmane.comp.lang.racket.user/16384" target="_blank">http://thread.gmane.org/gmane.comp.lang.racket.user/16384</a> `sequence->list' uses the sequence API to make a copy of its input. This can dominate the running time of functions that look like this: (define (f xs) (let ([xs (sequence->list xs)]) ... simple O(n) computation using xs ...)) Also, it seems wasteful to make a copy if `xs' is already a list. I'd like to change the definition of `sequence->list' from this: (define (sequence->list s) (for/list ([v s]) v)) to this, to handle the two most common sequences specially: (define (my-sequence->list s) (cond [(list? s) s] [(vector? s) (vector->list s)] [else (for/list ([v s]) v)])) For vectors, I measure a 3x speedup. For lists, it's of course O(1). It's a semantic change, but I can't imagine anyone relying on this fact: (not (eq? xs (sequence->list xs))) If someone does, [(list? s) (map values s)] would preserve that fact, and is 3x faster in my measurements. Thoughts? Neil ⊥ _________________________ Racket Developers list: <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> </blockquote></div> </div>