Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10

Subject: Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-07-02 03:44:33

On Sat, Jul 1, 2017 at 6:20 PM, Zach Laine via Boost
<boost_at_[hidden]> wrote:
> They don't seem that different to me.  The data look the same from the
> outside, but the underlying structure is different.  The underlying
> structure doesn't seem like it *needs* to be different, though.  One could
> be flattened into the other.  These are all views, right?  Cheap-to-copy
> views?  So, in terms of the existing types, if buffer_cat() returned a
> buffer_prefix_view with n=0, would that break things?  I mean a semantic
> breakage, not a compilation breakage.

Perhaps it is possible to combine the functionality of
buffer_prefix_view and buffer_cat_view, but it would come at the
expense of a larger object. Buffer sequences are supposed to be
copyable and normally they are not particularly large. For example
beast::multi_buffer::const_buffers_type costs just one pointer and
therefore pretty darn cheap. But some parts of Beast declare truly
gnarly buffer sequences, like this one:
<https://github.com/vinniefalco/Beast/blob/78a065ba39836d91d7e70d93de7f9140f518083b/include/beast/http/serializer.hpp#L190>

    using ch2_t = consuming_buffers<buffer_cat_view<
       detail::chunk_header,
       boost::asio::const_buffers_1,
       boost::asio::const_buffers_1,
       typename reader::const_buffers_type,
       boost::asio::const_buffers_1,
       boost::asio::const_buffers_1,
       boost::asio::const_buffers_1,
       boost::asio::const_buffers_1>>;

reader::const_buffers_type can itself be a buffer_cat_view or some
other sort of adapted buffer sequence, it depends on the traits of the
Body being used.

Chris was very helpful in working with me to optimize the
http-server-fast example, he pointed out that the size of this buffer
was exactly 256 bytes which unfortunately is one byte larger than it
needs to be in order to take advantage of an Boost.Asio implementation
optimization. I got lucky and found an unused member in
consuming_buffers which I was able to remove.

The moral of the story is that sizeof(ConstBufferSequence) counts, so
these buffer range adapters need to be separate in order to be as
small as possible.

Thanks