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

Reply via email to