Announcing Elembuf

Steven Schveighoffer schveiguy at gmail.com
Wed Dec 19 18:24:55 UTC 2018


On 12/19/18 12:54 PM, H. S. Teoh wrote:
> On Wed, Dec 19, 2018 at 11:56:44AM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote:
>> 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.

The expectation in iopipe is that async i/o will be done a-la vibe.d 
style fiber-based i/o.

But even then, the cost of copying doesn't go up -- if it's negligable 
in synchronous i/o, it's going to be negligible in async i/o. If 
anything, it's going to be even less noticeable. It was quite a 
disappointment to me, actually.

-Steve


More information about the Digitalmars-d-announce mailing list