Re: [boost] asio networking proposal

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-19 09:47:11

From: Thore Karlsen <sid_at_[hidden]>
> On Fri, 19 Aug 2005 09:08:59 -0400, Rob Stewart <stewart_at_[hidden]> wrote:
> 
> >> The performance problems of requiring vector<char> or char[N] exist on
> >> several levels:
> >> 
> >> - For vector<char>, there is the initialisation of the chars to 0 on
> >> construction or when you do a resize. Note that this is proportional to
> >> the size of the vector, not necessarily to the amount of data
> >> transferred. I have seen this have a noticable cost in a CPU-bound
> >> server handling thousands of connections.
> 
> >Don't construct a vector of a given size or use resize(), then.
> >Rely on reserve() instead.
> 
> Then size() will return the wrong value, and relying on capacity() is

No, size() will correctly indicate that there are no objects in
the vector.

> not a good idea. If you're thinking about pushing data onto the vector

Why is relying on capacity() a bad idea?

> as it's read, that's also bad, because then you'd have to read into a
> temporary buffer first and copy it to the vector after. (Or do multiple
> resizes.)

At some point, the vector has to have sufficient elements in it
so that you can copy new values onto them.  Otherwise, the vector
won't know it has real elements.  Yes, that means you do pay for
the initialization at some point and, yes, that isn't desirable.

> I think it's a very bad idea to require vector<char> or a static array.
> Christopher does a good job of explaining the drawbacks, and I agree
> with him. I also do high performance asynchronous networking in my
> server and client applications, and a library requiring vector<char> or
> a static array would be completely useless to me. Most of the time I
> don't have the data I want to send in a vector or in a static array, and
> most of the time the amount of data is too big to send or receive a
> whole buffer at a time.

I understand.

> >> - Requiring a copy from a native data structure into vector<char> or
> >> char[N]. If I have an array of a doubles say, I should be able to send
> >> it as-is to a peer that has identical architecture and compiler.
> >> Avoiding unnecessary data copying is a vital part of implementing high
> >> performance protocols.
> 
> >Agreed.  OTOH, using swap(), *if* a user used a vector<double>
> >instead of the array you mention, then vector won't add overhead.
> 
> Why would a swap be necessary?

If asio used a vector, the user could swap it's contents into his
own vector.  (That's not the current interface, but then neither
is vector in the current interface.  It was just informational
for the discussion.)

> >Instead, how about a std::vector-like class that takes a
> >user-defined, fixed-size block of memory?
> 
> No, that would still require a copy if the data isn't already in such a
> buffer. void * (or unsigned char *, or char *, or whatever) HAS to be
> there, otherwise the library is useless. Such a class could be an option
> (and I would like to see it as an option), but not a requirement.

I don't think you understand what I'm suggesting.  Notice that I
used the word "takes."  Furthermore, I think you snipped the
details about how that class would use the buffer handed to it.

The data has to be in some memory somewhere.  The class I'm
suggesting can be told to use that memory and can be told how
much memory is available.  Then, whenever asio needs to read data
into the caller's buffer, or write data from the caller's buffer,
it is taken from that preexisting buffer.

> In my applications I can't afford to copy data from my internal buffers
> to whatever the networking library requires. I also can't put the data
> in such buffers to begin with.

So wrap your internal buffers with the class I'm suggesting.  No
copy is needed.  The class simply provides a standard interface,
complete with push_back(), iterators, random access, etc., and
prevents buffer overruns.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;