On Wed, Dec 19, 2018 at 11:56:44AM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote: > 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: [...] > > > 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. [...]
Ahh, that makes sense. Did you test async I/O? Not that I expect any difference there either if you're I/O-bound; but reducing CPU load in that case frees it up for other tasks. I don't know how easy it would be to test this, but I'm curious about what results you might get if you had a compute-intensive background task that you run while waiting for async I/O, then measure how much of the computation went through while running the grep-like part of the code with either the circular buffer or the moving buffer when each async request comes back. Though that seems like a rather contrived example, since normally you'd just spawn a different thread and let the OS handle the async for you. T -- Жил-был король когда-то, при нём блоха жила.