etc.curl: Formal review begin

Marco Leise Marco.Leise at gmx.de
Wed Aug 31 17:00:32 PDT 2011


Am 31.08.2011, 22:53 Uhr, schrieb Johannes Pfau <spam at example.com>:

> Andrei Alexandrescu wrote:
>>
>> This will happen all the more if you have multiple threads.
>>
>> You clearly have a good expertise on OS, I/O, and related matters, and
>> I am honoured by your presence and by the value you're adding to this
>> group. However, in this particular argument you're only firing blanks.
>> Are you sure you have a case?
>>
>>
>> Andrei
>
> So why don't we benchmark this?
> Here's a first, naive attempt:
> https://gist.github.com/1184671
>
> There's not much to do for the sync implementation, but the async one
> should maybe keep a pool of buffers and reuse those. However, the async
> implementation was already ~10% faster in simple tests (copying a 700mb
> ubuntu .iso; source and target on the same harddisk). I wouldn't have
> expected this, but it seems the async copy is actually be faster.

I cannot verify your numbers at all. I drop the caches before every run  
and make two runs with --async first and --sync second and two runs the  
other way round. On a 1GB file the async version adds an average of 0.22%.  
With a larger buffer size that margin increases even more. Did you  
actually clear the disk cache before runs and no other application used  
the disk much? Browsers tend to save the session in intervals. At the  
bottom of your heart you know that your numbers must be wrong. :p Verify  
it once more!


More information about the Digitalmars-d mailing list