etc.curl: Formal review begin

["Jérôme M. Berger"]

Andrei Alexandrescu wrote:
> On 08/31/2011 02:15 PM, Marco Leise wrote:
> [snip]
>>> If I understand the above correctly, the same amount of seeking goes
>>> around in both cases. The only difference is that requests come at a
>>> faster pace, as they should.
>>>
>>> Andrei
>>
>> That's not what I wanted to say. Let me put it like this: If you read
>> the file in one call to read and the write the whole thing from your
>> buffer you have only 2 of these 'long' seeks.
> 
> Yes. It is fair to assume that the asynchronous case uses buffers of the
> same length as the synchronous case. Then the grand total number of
> seeks will be the same or better for the asynchronous version (better if
> the OS handles concurrent seek requests cleverly with some elevator
> algorithm).
> 
	No, it would be fair to assume that the total buffer size is the
same in both cases, which means that the asynchronous buffers will
have size 1/n times the synchronous buffer size (where n is the
number of threads). Which means that the asynchronous version will
issue n times as many seeks. Now you are right that those seeks will
be issued in a more efficient manner (especially since they can
probably be sent to the disk before the ongoing transfer is
completed). Whether the efficiency gain will offset the increased
number of seeks, I do not know but I doubt it...

		Jerome
-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110831/1165c1a6/attachment.pgp>