streaming redux

Michel Fortin michel.fortin at michelf.com
Tue Dec 28 12:14:01 PST 2010


On 2010-12-28 12:47:26 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 12/28/10 11:34 AM, Michel Fortin wrote:
>> 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?

Well, theoretically, adding a buffer between us and the stream should 
allow us to play with our buffer and flush only when we have a big 
chunk of data, making the virtual call overhead irrelevant. But for 
this to work, we need to manipulate the buffer free of virtual calls; 
this doesn't really work with BufferedOutputTransport as an interface.

One way you could achieve this by making BufferedOutputTransport an 
abstract class that implements UnbufferedOutoutTransport's write method 
as a final function and leaves abstract (and virtual) only the buffer 
flushing method (and other things related to the underlying stream). 
This will make BufferedOutoutTransport's implementation of buffering 
hard to change, but how many buffer implementation do we really need?

So this should eliminate about half of the virtual calls, provided 
Formatter knows at compile time it is speaking to a buffered stream. As 
for the other half, when calling Formatter's functions, see my earlier 
post.


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



More information about the Digitalmars-d mailing list