[plt-scheme] Statistics for Sequences

From: Doug Williams (m.douglas.williams at gmail.com)
Date: Thu Sep 10 11:03:24 EDT 2009

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.

On Thu, Sep 10, 2009 at 8:47 AM, Jakub Piotr Cłapa <jpc-ml at zenburn.net>wrote:

> On 09-09-10 16:30, Doug Williams wrote:
>> 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.
> 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
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20090910/c6f4bb0b/attachment.html>

Posted on the users mailing list.