etc.curl: Formal review begin

[Josh Simmons]

On Thu, Sep 1, 2011 at 10:00 AM, Marco Leise <Marco.Leise at gmx.de> wrote:
> 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!
>

Not sure why we're evaluating disk access performance patterns when
dealing with network throughput which is only copying the data from
userspace to a kernel buffer provided you're using a proper async
socket access pattern. Implemented properly there is absolutely no
need to complicate the whole show with threading (unless you're on
windows where there's only IOCP). At any rate curl provides an async
api which one would assume is relatively sane so once again I'm not
sure how this speculation is appropriate.

I'll also note that I doubt very much that this cost would be
significant in any way when compared to http overhead.

As well as this, as an API issue I don't think a shortcut method for
avoiding the HTTP verb is a good idea. Being explicit as to what
you're doing is very much appropriate and hiding the verb because you
don't have any understanding of HTTP is not a fantastic decision.