On 05/16/12 22:58, Steven Schveighoffer wrote: > On Wed, 16 May 2012 16:38:54 -0400, Artur Skawina <art.08...@gmail.com> wrote: > >> On 05/16/12 22:15, Steven Schveighoffer wrote: >>> I still don't get the need to "add" this to ranges. The streaming API >>> works fine on its own. >> >> This is not an argument against a streaming API (at least not for me), but >> for efficient ranges. With the API above I can shift tens of gigabytes of >> data per second between threads. And still use the 'std' range API and >> everything that works with it... > > But you never would want to. Don't get me wrong, the primitives here could > work for a streaming API (I haven't implemented it that way, but it could be > made to work). But the idea that it must *also* be a std.range input range > makes zero sense.
Well, I do want to. For example, I can pass the produced data to *any* range consumer, it may be as efficient as mine, but will still work reasonably (I just did a quick test and the difference seems to be about 10G/s less for plain front+popFront consumer). The goal here is: if we could agree on a standard interface then *any* producer and consumer, including the ones in the std lib could take advantage of this (optional) feature. It's not so much about function call overhead as /syscall/ and /locking/ costs. Retrieving or writing 100 elements with only one lock-unlock sequence makes a large difference. > To me, this is as obvious as not supporting linklist[index]; Sure, it can be > done, but who would ever use it? This is not even related. Your 'read(ref ubyte[])' approach can actually mean that one more copy of the data is required. Think writer->range_or_stream->reader -- unless the reader is already waiting with an empty buffer, the stream has to copy the data to an internal buffer, which then has to be copied again when a reader comes around. The 'slice[] = fronts' solution avoids the second copy. Like I said, depending on the circumstances, sometimes you want one scheme, sometimes the other. (TBH, right now i can't think of a case where i'd prefer a non-range based approach; having the same i/f is just so convenient. But I'm sure there's one ;) ) artur