Actually, I'd like to dig into the sequence code (specifically, sequence-generate) that should give you the sequencing function dynamically. I'm not sure why it isn't as efficient as anything the for macro can generate for vectors. <div class="gmail_quote">On Thu, Sep 10, 2009 at 8:47 AM, Jakub Piotr Cłapa <<a href="mailto:jpc-ml@zenburn.net">jpc-ml@zenburn.net</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">On 09-09-10 16:30, Doug Williams wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> It's interesting that if I use (in-vector ...) in the for/fold statements, the times for the for/fold version are about the same as for the (uglier) do version (with vector-refs). [This one probably would benefit from Matthew's performance improvements.] Actually using it would mean giving up the flexibility in going to sequences in the first place, but it means there is some hope of eventually getting the same performance for the sequence versions (at least for vectors). using in-vector in the for cpu time: 266 real time: 265 gc time: 0 cpu time: 250 real time: 250 gc time: 47 current science collection routines cpu time: 250 real time: 249 gc time: 0 cpu time: 218 real time: 218 gc time: 16 It would be nice if (for ((x some-vector)) ...) and (for ((x (in-vector some-vector))) ...) had similar performance. I realize that at expansion time the latter knows to expect a vector while the former does not and can generate code accordingly. But, I can dream. </blockquote> </div> AFAIU you could special case vectors (duplicating the code) if you expect them to be used frequently. Probably a for-like macro expanding into shortcuts for specified fast iterators would be nice to have. Something like (for ([x (in (list vector string) lst)]) x) would expand to (cond [(list? x) (for ([x (in-list lst)]) x)] ... [else (for ([x lst]) x)]) PS. And what about generating such special cases by evaling a dynamically generated lambda at runtime? I guess it would make really long iterations faster but the eval overhead would kill the performance for short ones? -- regards, Jakub Piotr Cłapa<div><div></div><div class="h5"> _________________________________________________ For list-related administrative tasks: <a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a> </div></div></blockquote></div>