Announcing Elembuf

[Steven Schveighoffer]

On 12/18/18 8:41 PM, H. S. Teoh wrote:
> On Tue, Dec 18, 2018 at 01:56:18PM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote:
>> On 12/18/18 10:36 AM, H. S. Teoh wrote:
>>> On Tue, Dec 18, 2018 at 08:00:48AM +0000, Cyroxin via Digitalmars-d-announce wrote:
>>>> [...] While the focus of this library is in socket receival,
>>>> reading from a file doesn't seem to be bad either.
>>> [...]
>>>
>>> Ahh, I see. I thought the intent was to read from a file locally. If
>>> you're receiving data from a socket, having a circular buffer makes
>>> a lot more sense.  Thanks for the clarification.  Of course, a
>>> circular buffer works pretty well for reading local files too,
>>> though I'd consider its primary intent would be better suited for
>>> receiving data from the network.
>>
>> Although I haven't tested with network sockets, the circular buffer I
>> implemented for iopipe
>> (http://schveiguy.github.io/iopipe/iopipe/buffer/RingBuffer.html)
>> didn't have any significant improvement over a buffer that moves the
>> data still in the buffer.
> [...]
> 
> Interesting. I wonder why that is. Perhaps with today's CPU cache
> hierarchies and read prediction, a lot of the cost of moving the data is
> amortized away.

I had expected *some* improvement, I even wrote a "grep-like" example 
that tries to keep a lot of data in the buffer such that moving the data 
will be an expensive copy. I got no measurable difference.

I would suspect due to that experience that any gains made in not 
copying would be dwarfed by the performance of network i/o vs. disk i/o.

-Steve