streaming redux

[Andrei Alexandrescu]

On 12/28/10 11:34 AM, Michel Fortin wrote:
> On 2010-12-28 11:09:01 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>> On 12/28/10 5:09 AM, Vladimir Panteleev wrote:
>>> First of all: was ranges-like duck typing considered for streams? The
>>> language allows on-demand runtime polymorphism, and static typing allows
>>> compile-time detection of stream features for abstraction. Not sure how
>>> useful this is is practice, but it allows some optimizations (e.g. the
>>> code can be really fast when working with memory streams, due to
>>> inlining and lack of vcalls).
>>
>> I think static polymorphism is great for ranges, which have fine
>> granularity, but not for streams, which have coarse granularity. One
>> read/write operation on a stream is likely to do enough work for the
>> dynamic dispatch overhead to not matter.
>
> You're assuming streams will deal with I/O operations. What if I have a
> pipe between two processes on the same machine?

That's solid work all right.

> What if I'm serializing
> an object before passing it to another thread?

That too.

> What if I just want to
> calculate the checksum for a serialized object without writing it
> anywhere? Should I create my own stream system for these cases?

I'd guess so. I'm not getting your drift.

> As for fine/coarse granularity, that's somewhat true when the stream is
> buffered before the virtual calls, but do you realize that using
> Formatter to output bytes can easily result in two virtual calls per
> byte for calling mostly trivial functions that could easily be inlined
> otherwise? First virtual call: Formatter.put(byte), which then calls
> UnbufferedOutputTransport.write(byte[1]).

Ideas on how to mitigate that?


Andrei