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