Re: Dismal ostream performance

On Nov 22, 6:49 am, Vaclav Haisman <v.hais...@sh.cvut.cz> wrote:


as I seem to think??

No I think it's quite possible that the poor performance is inevitable
in a conforming implementation. It might be difficult to prove
though.


Depending on the abstraction that penalty can be made quite small. I
am convinced that in this case one can have one's cake and eat it too.

I already achieve separation of the formatting and storage through a
pure abstract base class for an output octet stream:

struct IOutputOctetStream
{
   virtual ~IOutputOctetStream() {}
   virtual void Write(const OCTET* buffer, size_t count) = 0;
   virtual void Flush() = 0;
};

This could just as easily be templatised on an element type T rather
than assume it's an octet.

My implementation of a buffered octet stream provides non-virtual
methods to write individual octets or arrays of octets. It stores a
pointer to an underlying IOutputOctetStream and only calls the above
virtual Write() method when the buffers are full or explicitly
flushed. I find that a buffer of only a few kilobytes is sufficient
to amortise away the overhead of the virtual calls.

This is getting off-topic, but I will add that unlike the standard
library streambuf my implementation:
- Has better cohesion in the sense that it doesn't support both
reading and writing which IMO should be orthogonal.
- Cleanly separates output buffering from the pure abstraction of an
output stream, which are distinct concepts.
- Fully hides the buffering from clients so the interface is simple
and elegant. E.g. there is no counterpart to pubsetbuf.
- Follows the open/closed principle more directly because the
implementation of buffering is closed. My buffered stream class has
no virtual methods and there is never a need for clients to subclass
it.

I have investigated what could be done to support I18N. I think
polymorphism using pure abstract base classes is appropriate. For
example, the following approach allows for complete flexibility in how
an int is formatted:

struct IIntFormatter
{
   virtual void Write(my_ostream& os, int x) = 0;
};

class my_ostream
{
public:
   void Write(int x) { intFormatter_->Write(*this,x); }
   ...

private:
   IIntFormatter* intFormatter_;
   ...
};

inline my_ostream& operator<<(my_ostream& os, int x)
{
   os.Write(x);
   return os;
}

I have implemented this to measure the overhead of the indirection
(i.e. virtual call through a pointer). For writing 1 million integers
in decimal that appear as '10' in the output the result is:

   Microsoft: 1.4 MHz
   Mine (without indirection): 33 MHz
   Mine (with indirection): 32 MHz

This is not unexpected - virtual calls aren't very expensive.

In the case of the indirection, the following:

int value = 10;
for (int i=0 ; i < 1000000 ; ++i)
{
   os << value;
}

was compiled as:

00402BFF mov esi,0F4240h
00402C04 mov ecx,dword ptr [esp+160h]
00402C0B mov eax,dword ptr [ecx]
00402C0D mov eax,dword ptr [eax]
00402C0F push 0Ah
00402C11 lea edx,[esp+150h]
00402C18 push edx
00402C19 call eax
00402C1B sub esi,1
00402C1E jne 00402C04

There is no doubt that a virtual method call was taken to write each
integer value.

Evidently supporting I18N with complete generality can be achieved
with minimal overhead.

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]