streaming redux

[Michel Fortin]

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? What if I'm serializing 
an object before passing it to another thread? 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?

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]).

If you restrict virtual calls so they only happen when flushing the 
buffer, then you have a coarse granularity, as you're passing many-byte 
buffers through those virtual functions. But otherwise it's quite 
wasteful.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/