On Thu, Jun 6, 2013 at 4:13 PM, Daniel Micay <danielmi...@gmail.com> wrote:
> On Thu, Jun 6, 2013 at 6:19 PM, Vadim <vadi...@gmail.com> wrote:
> >
> > Based on my experience with iterators in other languages, I would like
> throw
> > in the following idea:
> >
> > pub trait BlockyIterator<A> {
> > /// Advance the iterator and return the next block of values.
> > Return empty vector when the end is reached
> > fn next(&mut self) -> &'self [A]
> > }
> >
> > Rationale: when concrete type of the iterator is known, the next() method
> > inlines nicely. However, when used polymorphically, every iterator
> > advancement turns into a function call. A lot of that overhead could be
> > shaved off, if iterators can return multiple values at a time. A
> "normal"
> > Iterator can then be implemented on top of this trait.
> >
> > This is especially applicable to types which already store elements in an
> > vector, most notably [T] itself.
>
> As you've mentioned, the existing Iterator trait allows you to return
> data in blocks if you desire (Iterator<&[T]> or Iterator<~[T]>).
>
Essentially only vectors and vector-based deques can return a slice,
> so it wouldn't really be a generic trait.
>
The iterator object itself can contain a fixed size buffer into which it
copies objects before returning slice to the caller. This would work for
almost any container type.
Perhaps I'm confused about the amount of inlining that Rust can perform.
Do you expect that iterator.next() calls will be inlined across crate
boundaries?
Coroutines/generators are quite cool, but they're far from free if
> they're implemented with context switching between code and not with a
> state machine - a switch involves swapping the registers and wiping
> out a lot of the cache.
>
Hmm, yes, that true...
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
